Bug 35830

Summary:	%check под mipsel
Product:	Sisyphus	Reporter:	Ivan A. Melnikov <iv>
Component:	zstd	Assignee:	placeholder <placeholder>
Status:	CLOSED FIXED	QA Contact:	qa-sisyphus
Severity:	normal
Priority:	P3	CC:	glebfm, jqt4, ldv, placeholder, sin, vt
Version:	unstable
Hardware:	all
OS:	Linux
URL:	https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876416#17

Description Ivan A. Melnikov 2018-12-30 16:24:43 MSK

Один из тестов zstd проверяет распаковку в 999 потоков. Учитывая, что ulimit -s на mipsel по умолчанию равен 8192, столько потоков никак не помещаются в скромное адресное пространство одного процесса (на mipsel это 2GiB на userspace).

Для прохождения тестов достаточно уменьшить ulimit -s, например так:

http://git.altlinux.org/people/iv/packages/zstd.git?p=zstd.git;a=commitdiff;h=1e945d5d64e86bd52830039a7f0f4b371bbf34d4

В таком виде %check проходит успешно и пакет собирается в sisyphus_mipsel.

Прошу включить такое или аналогичное изменение в следующую сборку zstd.

Comment 1 Dmitry V. Levin 2018-12-30 17:06:52 MSK

Интересно, а почему на x86 помещается, там ведь тоже есть это 32-битное ограничение на размер адресного пространства.

Comment 2 Ivan A. Melnikov 2018-12-30 19:15:14 MSK

(In reply to comment #1)
> Интересно, а почему на x86 помещается, там ведь тоже есть это 32-битное
> ограничение на размер адресного пространства.

А у нас на i586 ulimit -s не меньше?

К тому же, на mips* старший бит адреса используется как признак kernel space, так что адресного пространства там в два раза меньше чем на x86* той же разрядности.

Comment 3 Dmitry V. Levin 2018-12-30 19:21:14 MSK

(In reply to comment #2)
> (In reply to comment #1)
> > Интересно, а почему на x86 помещается, там ведь тоже есть это 32-битное
> > ограничение на размер адресного пространства.
> 
> А у нас на i586 ulimit -s не меньше?

Нет, у нас дефолтный ядерный ulimit -s.
Поскольку i586 собирается на x86_64, то и ulimit -s одинаковый.

Comment 4 Ivan A. Melnikov 2019-08-05 16:11:16 MSK

(In reply to comment #1)
> Интересно, а почему на x86 помещается, там ведь тоже есть это 32-битное
> ограничение на размер адресного пространства.

В честь очередного обновления zstd я решил всё-таки разобраться, что там за магия. Оказалось, что количество потоков в zstd (в частности управляемое через -T<number>) ограничено сверху специальной константой, ZSTDMT_NBWORKERS_MAX. По умолчанию эта константа равна 200, так что на самом деле 999 потоков в тестах не создаётся никогда, в том числе и на x86_64. Получается, что 200 worker'ов в 4 Гб адресного пространства на i586 влезают, а в 2 Гб на mipsel -- нет.

Помимо пространства для стека, каждому потоку нужны различные буферы, так что количество возможных worker'ов заметно меньше, чем количество потоков, которые можно успешно создать. В частности, на mipsel на моих тестах в конфигурации по умолчанию можно запустить не больше 79 worker'ов. На всякий случай я снизил ограничение на размер пула потоков до 64х. Так что теперь исправление для mipsel выглядит так:

http://git.altlinux.org/people/iv/packages/?p=zstd.git;a=commitdiff;h=baf76935219eaf52cee57700a37cd29722fa42b6

С таким изменением пакет успешно собирается.

Comment 5 Dmitry V. Levin 2019-08-05 17:55:57 MSK

А в Debian просто тупо выключили тесты.

Comment 6 Dmitry V. Levin 2022-04-09 11:44:25 MSK

Apparently, it was fixed in 1.5.0-alt1 by upstream commit v1.5.0^2~3^2~1:
https://github.com/facebook/zstd/commit/cb0cad9b79669185677383d8d7fd502257374fd2