[devel] racket cpu hog (was: CPU time limit exceeded)

[Anton Farygin]

On 24.10.2022 10:47, Anton Zhukharev wrote:
> On Sun, Oct 23, 2022 at 10:37:44PM +0300, Anton Farygin wrote:
>> On 23.10.2022 22:05, Vitaly Chikunov wrote:
>>> Anton,
>>>
>>> On Sun, Oct 23, 2022 at 09:52:39PM +0300, Anton Zhukharev wrote:
>>>> On Sun, Oct 23, 2022 at 08:25:05PM +0300, Dmitry V. Levin wrote:
>>>>> On Sun, Oct 23, 2022 at 12:39:16PM +0300, Anton Zhukharev wrote:
>>>>>> Добрый день!
>>>>>>
>>>>>> Недавно столкнулся с проблемой следующего вида:
>>>>>>
>>>>>> [ppc64le] /usr/sbin/chroot.fakechroot: line 147: 2435617 CPU time limit exceeded env -u FAKECHROOT_BASE_ORIG FAKECHROOT_CMD_ORIG= LD_LIBRARY_PATH="$fakechroot_chroot_paths" FAKECHROOT_BASE="$fakechroot_chroot_base" "$fakechroot_chroot_chroot" "${@:1:$(($fakechroot_chroot_n - 1))}" "$fakechroot_chroot_final_newroot" "${@:$(($fakechroot_chroot_n + 1))}"
>>>>>> 2022-Oct-22 21:18:00 :: [ppc64le] racket-main-distribution.git 8.6-alt1: remote: build failed
>>>>>> 2022-Oct-22 21:18:00 :: [ppc64le] #100 racket-main-distribution.git 8.6-alt1: build FAILED
>>>>>>
>>>>>> в задании 308872.
>>>>>>
>>>>>> Насколько я понимаю, эта ошибка связана с разделением времени работы
>>>>>> процессора между пользовательскими процессами (воспроизвелась только на
>>>>>> архитектурах i586, armh и ppc64le - на x86_64 и aarch64 полёт нормальный).
>>>>>>
>>>>>> Есть способ обхода такого ограничения?
>>>>> Сделать так, чтобы racket перестал быть таким неуёмно прожорливым,
>>>>> что особенно проявляется на более медленных архитектурах.
>>>>>
>>>> Это, конечно, не лучшее решение, но сделав установку Racket-пакетов в
>>>> 1 поток (-j 1), пакет стал собираться (см. задание 308872).
>>>>
>>>> Похоже, что планировщик в установщике пакетов Racket'а работает не очень
>>>> оптимальным образом.
>>>>
>>>> Что ж, решение найдено. Процесс сборки стал дольше (кстати, не сильно),
>>>> однако мне важен результат, а не скорость.
>>>>
>>>> Осталось подлатать и в репозитории будет Racket ;).
>>> Racket уже был в Сизице до 2022-06-18. Может стоит базироваться на
>>> старом спеке. Например, назвать пакет racket.
>>>
>> Кстати да, лучше конечно наследование какое-то сделать.
>>
> Я изначально пробовал исправить уже существующий спек, однако
> пришлось отключать сборку на ppc64le, поскольку она повисала намертво (в
> действительности это не так: при сборке с помощью make ничего не
> выводится в терминал в течение продолжительного времени (больше часа) и
> из-за этого hasher считает, что сборка повисла - однако если собирать с
> помощью zuo (их собственная система сборки - собрал отдельно в Сизиф) то
> сборка "чинится", поскольку zuo выводит результат сборки каждого
> файла).
Под наследованием я имел в виду хотя-бы сохранение changelog'ов и 
описаний. Но нет так нет - это вообще на самом деле не критично, если 
работа делается с нуля.
>
>> https://github.com/racket/racket
>>
>> к тому же он и у апстрима называется racket.
>>
> Я решил разделить сборку минимального Racket и пакетов к нему:
> получились пакеты racket-base и racket-main-distribution.
>
> Скорее всего, необходимо ещё сильнее дробить.
Понятно.
> А почему бы не взять за основу апстримный git, кстати ?
> В апстриме спрашивал - ответили, что апстримный git использовать не
> советуется с целью опакечивания. См.: https://github.com/racket/racket/issues/4456#issuecomment-1277449129

Ну апстримы, как правило, всегда предпочитают сборку из релизных 
тарболлов, просто для сопровождения удобнее иметь git, а не импорт.