время установки , небольшое ускорение

Calculate Русский
1

В .config calculate-sources указан http://cateee.net/lkddb/web-lkddb/SQUASHFS_DECOMP_MULTI_PERCPU.html

..
CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU=y
..

установка занимает :
http://imglink.ru/show-image.php?id=9c7c01581dc9d4262f7b74fc069aa56c

если поменять на http://cateee.net/lkddb/web-lkddb/SQUASHFS_DECOMP_MULTI.html

..
CONFIG_SQUASHFS_DECOMP_MULTI=y
..

то установка занимает :
http://imglink.ru/show-image.php?id=5d6f0569de80737e2c10caec954432b1

*использовал одну и ту же флешку/раздел/iso , железки :

Drives:model: ST3400620AS
CPU:Triple core AMD A6-3500 APU with Radeon HD Graphics
Silicon-Power8G UFD 2.0
2

Из обсуждения здесь я так понял, что по мнению разработчиков свои плюсы и минусы имеют обе реализации и быстродействие одного или второго варианта в достаточной степени зависит от конфигурации и загруженности системы.

CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU - размещает по одному потоку декомпрессора на каждом ядре статически. В теории работает стабильнее.

CONFIG_SQUASHFS_DECOMP_MULTI - размещает потоки декомпрессора по ядрам динамически. До двух потоков на ядро. То есть в гипотетической ситуации, если у 3-х ядерного процессора 1 ядро загружено сильно, одно неммного и третье вовсе простаивает, то в данной ситуации на простаивающее ядро будет повешено два потока, на средне-загруженное вероятно 1 поток и на сильно загруженное 1 или ни одного даже.

Вероятно, что в большинстве случае действильно будет выигрыш от использования CONFIG_SQUASHFS_DECOMP_MULTI

3

Iurii Blokhin wrote:

CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU - размещает по одному потоку декомпрессора на каждом ядре статически. В теории работает стабильнее.

стабильнее это как … подробней можно ?
зы . пользуюсь CONFIG_SQUASHFS_DECOMP_MULTI не первый раз … на 13 кальке разница по времени была побольше и проблем никаких небыло :slight_smile:

4

Возможно неправильно выразился. Я об этой части обсуждения по ссылке:

Taking an percpu variable is an exclusive lock on that core. Whilst that 
percpu variable is held it ensures nothing else can be scheduled on that 
core. Any other parallel decompressions will by definition be guaranteed 
to be scheduled on another core. 

Without percpu variables, and parallel threads it is entirely up to 
the scheduler whether it schedules them on different cores, or schedules 
both threads on the same core.