>>Нет. До сих пор правило N+1 работает хорошо, потому как запасной
>>процесс именно на I/O и подскакивает своё отработать.
>Даже если речь идет о каком-нить Dual Xeon'е, где, собсно 2 чесных
>проца, Это в смысле Katmai какие? Ну вот стоит Quad на площадке, один из тех, о ком речь. В т.ч. занимается сборкой (точнее, года полтора назад ещё активно занимался, сейчас скорее изредка).
>а два так, поржать (HT)
Это в P4-based... и именно что поржать, учесть их толком не получается -- где чуточку лучше, где на треть хуже.
>то даже в таком случае CPUs+2 будет более оптимальной формулой,
>чем CPUs+1. 2*CPUs - это именно на честных сабжах.
Простите, но на нечестных можно только гадать.
>>Вы предлагаете то, что склонно приводить к scheduler thrashing -- оверхед
>>на переключение начинает быть заметен.
>Потери переключений/потери кеша ничто в сравнении с простоем проца и (уж тем
>более!) винта.
Да, но если затыков в I/O особенных нет (при той же сборке это типично -- надо чем-то выжрать всю полосу пропускания типичного для заданной системы стораджа, чтоб сборка начала голодать именно по диску) -- то оверхед начинает быть заметен.
>>>Они уже в кеше.
>>И тут их оттудова выпинывают, потому как слайс закончился... (я про CPU
>>cache)
>Я вообще-то был об FS cache.
Да понятно ;)
>Ну а если про CPU cache - то и тут все не так мрачно.
>Когда в конкурентной работе (на одном проце) два (или n+1) процесса с
>одинаковыми страницами кода, то даже при переключении контекста, кеш не будет потерят,
>т.к. оба процесса использовали одни и те же страницы.
Это "когда". Посмотрите на working set типичного cc1 и размер кэшей того, что под рукой...
>Время, затраченное на чтение исходника и запись бинаря, много меньше чем на
>процесс компиляции. Вывод: если хоть один проц простаивает или в состоянии
>iowait - то вы недогрузили сборочную машину.
Именно.
>Это намного страшнее по временным затратам, чем напряги шедулера.
>Практически всегда при сборке процы загрузить намного проще, чем винт.
Сдуру перегрузить можно и то, и другое.
>>PS: и для связок навроде apache+mysql, которые зачастую более i/o bound --
>>тоже глупости.
>стоп-стоп
>Мы о сборке, а не о бешенных юзерах-программеро-дезигнерах, которые ни веб, ни
>крипты, ни базы писать не умеют. Там я вообще ничего не скажу кто
>чего и сколько хочет. Ибо _полный_ рандом.
Я просто добавил, что даже для _более_ i/o bound tasks, когда действительно на каждое ядро можно и нужно наваливать больше -- при полной прогрузке "это не так".
Собственно, для случая мелкого хостинга без больших затыков это оббенчивалось и разбиралось здесь: http://lists.altlinux.org/pipermail/sysadmins/2007-August/01...
Для сборки -- практическое правило остаётся вида Ncpu+M, а не Ncpu*M. При этом либо M всё равно мало по сравнению с Ncpu, либо фиксить надо не коэффициенты, а дисковую (возможно, переездом в память).
