[devel-distro] [Builder Live/Appliance] tmpfs

[Ildar Mulyukov]

On 11.11.2012 22:58:06, Michael Shigorin wrote:
> On Sun, Nov 11, 2012 at 01:58:47AM +0600, Ildar Mulyukov wrote:
> > Вот это я и имел в виду. На обычной машине разумный размер
> > tmpfs по  умолчанию --- сколько-то процентов от физической RAM.
> > На сборочнице  можно поднять рабочий каталог для сборки до
> > n*RAM (n > 1). При этом всё  прекрасно и когда нужно свопится,
> > это по моему опыту. Насколько я  помню, сейчас основные
> > хэшерницы работают именно в tmpfs.
> 
> Да, но на автомате я согласен разве что сделать автоматику,
> которая оставит не менее ~гига памяти под сборку (в моих тестах
> вроде бы больше ~400M не задействовалось, но мало ли).  И будто
> её уже даже делал когда-то...

Да, делал. Это livecd-tmpfs,
и мне кажется, тут надо подправить, т.к. цифры с большим запасом.

     39  guess_need()
     64          # some space must be set aside for the processes
     65          if [ "$RAM" -lt 4 ]; then DIFF=1; else DIFF=2; fi

это перебор. Для самого live-builder + gcc в hasher хватит и 0.5

     71                  # lower-memory systems will employ swap
     72                  if [ "$RAM" -lt 8 ]; then

ну и пусть... Тут весь фокус в том, чтобы доверить ядру, как  
распоряжаться памятью и свопом. [1]

ИМХО, надо оставить гарантированные 0.5G для процессов, а всю остальную  
VM="$(($RAM+$SWAP))" отдать под tmpfs. Это, однако, не значит, что ядро  
будет активно всё свапить, оно всё же довольно интеллектуальное в этом  
вопросе.
Впрочем, в этом месте хорошо было бы позвать эксперта, который сам  
держит и тюнит сборочницу (на ум приходит ldv@)

[1] Кстати, у ядра по свопу есть ещё кое-какие интересные "ручки":  
http://rudd-o.com/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that

-- 
Ildar