тормоза на семерке
Eugene Grosbein
А чего это стало с традиционным шедулером в FreeBSD 7.0-PRERELEASE?
Hа шестерке можно было запустить nice -n 10 make -j4 buildworld
и вообще не замечать, что оно там работает, а на 7.0-PRE
вкладки в firefox стали открываться по нескольку секунд,
а если перейти на соседний десктоп и вернуться - окошко firefox-а
перерисовывается за секунду или больше даже... Сорцы и obj
на md лежат.
Eugene
--
Чисто вороньи стаи поют не так красиво.
Eugene Grosbein
EG> А чего это стало с традиционным шедулером в FreeBSD 7.0-PRERELEASE?
EG> Hа шестерке можно было запустить nice -n 10 make -j4 buildworld
EG> и вообще не замечать, что оно там работает, а на 7.0-PRE
EG> вкладки в firefox стали открываться по нескольку секунд,
EG> а если перейти на соседний десктоп и вернуться - окошко firefox-а
EG> перерисовывается за секунду или больше даже... Сорцы и obj
EG> на md лежат.
Поправка: make -j3 (система двухьядерная). Да ещё ей не хватило
гигабайта на src и obj, шестерке хватало... Интересно, это сорцы
разбухли или gcc4 такие объектники делает?
Eugene
--
Древние врачи умели лечить всё. Они знали даже секрет бессмертия,
но унесли его в могилу, не оставив потомкам.
Vlad Gnatov
EG>> А чего это стало с традиционным шедулером в FreeBSD 7.0-PRERELEASE?
EG>> Hа шестерке можно было запустить nice -n 10 make -j4 buildworld
EG>> и вообще не замечать, что оно там работает, а на 7.0-PRE
EG>> вкладки в firefox стали открываться по нескольку секунд,
EG>> а если перейти на соседний десктоп и вернуться - окошко firefox-а
EG>> перерисовывается за секунду или больше даже... Сорцы и obj
EG>> на md лежат.
EG> Поправка: make -j3 (система двухьядерная). Да ещё ей не хватило
EG> гигабайта на src и obj, шестерке хватало... Интересно, это сорцы
EG> разбухли или gcc4 такие объектники делает?
Партия мудро решила, что ведро/мир собираюцца слишком быстро,
что внушает народу фривольные мысли и лишает чувства, что страна
доверила ему важную технику.
Внедрение gcc4 призвано устранить эту проблему.
(http://groups.google.com.ua/group/mailing.freebsd.stable/msg/67e46e12a6b3f839)
:
--cut--
Here are some buildworld measures (extract from a buildaton):
i386: 6.2-RELEASE
-j4: 746.08 real 1996.38 user 468.91 sys 1535.1 RSA
-j6: 595.31 real 1957.31 user 539.24 sys 2304.9 RSA
-j8: 534.21 real 1957.76 user 567.06 sys 3068.5 RSA
M1000: 492.64 real 1956.58 user 587.41 sys
100: 526.22 real 1936.98 user 559.49 sys 3073.8 RSA
M100: 474.26 real 1947.09 user 563.95 sys
-j10: 550.18 real 1975.54 user 588.33 sys
-j12: 550.23 real 1976.88 user 602.65 sys
-j16: 559.22 real 1972.19 user 634.29 sys
i386: 7.0-current (as of 10/16/2007) - SCHED_4BSD
-j4: 1072.64 real 2880.29 user 561.13 sys 1495.7 RSA
-j6: 842.91 real 2813.75 user 638.91 sys 2244.8 RSA
-j8: 758.48 real 2824.23 user 704.00 sys 2990.1 RSA
M1000: 696.12 real 2820.53 user 706.97 sys
100: 752.58 real 2809.97 user 685.35 sys 2993.2 RSA
M100: 666.58 real 2804.72 user 714.01 sys
-j10: 763.82 real 2843.44 user 743.77 sys
-j12: 785.12 real 2845.11 user 770.31 sys
-j16: 805.02 real 2848.06 user 819.53 sys
i386: 7.0-current (as of 10/16/2007) - SCHED_ULE
-j4: 1047.00 real 2857.59 user 486.93 sys 1494.2 RSA
-j6: 831.10 real 2793.94 user 524.58 sys 2242.6 RSA
-j8: 803.34 real 2796.46 user 552.56 sys 2991.0 RSA
M1000: 709.77 real 2793.20 user 572.27 sys
100: 785.18 real 2765.14 user 545.57 sys 2991.4 RSA
M100: 707.09 real 2769.88 user 572.92 sys
-j10: 813.36 real 2808.13 user 587.51 sys
-j12: 824.23 real 2817.60 user 618.00 sys
-j16: 856.11 real 2847.68 user 721.97 sys
---------
Conditions:
Machine: Intel SR2520-S5000PAL,2xE5345(8 cores,2.33Ghz),8G,1xsata)
Generic kernel; /usr/obj/* removed after each run; Runs done after a
reboot; softupdates on all fs; RSA = openssl speed -multi <N> rsa1024;
M1000 = noatime /usr,kern.hz=1000,tar cf /dev/null /usr/src before run.
M100 = idem with kern.hz=100
100 = generic test with kern.hz=100 (To be compared with -j8 line).
(M variants to minimize disk contention reading src; Variants measured
only on #-core sweetspot (8 here)).
--cut--
Иногда мне кажется, что pcc или там llvm не такая уж плохая идея.
Eugene Grosbein
EG>>> А чего это стало с традиционным шедулером в FreeBSD 7.0-PRERELEASE?
VG> Use SHED_ULE, Luke.
Вот чего я не понимаю, так это когда отвечают вовсе не на тот
вопрос, который был задан. А вопрос был задан конкретно про SCHED_4BSD.
Я не спрашивал, как мне чего-нибудь улучшить, я спрашивал,
что случилось с традиционным шедулером - как ещё яснее можно
задать вопрос, чтобы надеяться получить ответ именно на него?
EG>>> Hа шестерке можно было запустить nice -n 10 make -j4 buildworld
EG>>> и вообще не замечать, что оно там работает, а на 7.0-PRE
EG>>> вкладки в firefox стали открываться по нескольку секунд,
EG>>> а если перейти на соседний десктоп и вернуться - окошко firefox-а
EG>>> перерисовывается за секунду или больше даже... Сорцы и obj
EG>>> на md лежат.
EG>> Поправка: make -j3 (система двухьядерная). Да ещё ей не хватило
EG>> гигабайта на src и obj, шестерке хватало... Интересно, это сорцы
EG>> разбухли или gcc4 такие объектники делает?
VG> Партия мудро решила, что ведро/мир собираюцца слишком быстро,
VG> что внушает народу фривольные мысли и лишает чувства, что страна
VG> доверила ему важную технику.
VG> Внедрение gcc4 призвано устранить эту проблему.
Во время тормозов на gcc3 говорили, что в gcc4 будет упор на оптимизацию...
Обманули? Семерка собирается почти на 10 минут дольше, 42 минуты
на 2x2.8Ghz, всё на RAM-диске.
VG> (http://groups.google.com.ua/group/mailing.freebsd.stable/msg/67e46e12a6b3f839)
Читал.
VG> Иногда мне кажется, что pcc или там llvm не такая уж плохая идея.
Это чего?
Eugene
--
Комбинация заискивания, подкупа и устрашения заставит молодого ученого
работать над управляемыми снарядами или атомной бомбой. (Hорберт Винер)
Eugene Grosbein
EG> Да ещё ей не хватило гигабайта на src и obj, шестерке хватало...
EG> Интересно, это сорцы разбухли или gcc4 такие объектники делает?
Судя по всему, и то и другое: сейчас исходники шестерки занимают 432Mb,
исходники 7.0-BETA1 уже 477Mb, но эта разница не настолько велика.
Значит gcc4 тоже виноват...
Eugene
--
За то, что сердце в человеке
Hе вечно будет трепетать
Valentin Nechayev
>>> Eugene Grosbein wrote:
EG> Во время тормозов на gcc3 говорили, что в gcc4 будет упор на оптимизацию...
EG> Обманули? Семерка собирается почти на 10 минут дольше, 42 минуты
EG> на 2x2.8Ghz, всё на RAM-диске.
Hу так оптимизация итогового кода требует времени компиляции.
Видимо, не обманули:))
-netch-
Vlad Gnatov
EG>>>> А чего это стало с традиционным шедулером в FreeBSD 7.0-PRERELEASE?
VG>> Use SHED_ULE, Luke.
EG> Вот чего я не понимаю, так это когда отвечают вовсе не на тот
EG> вопрос, который был задан. А вопрос был задан конкретно про
EG> SCHED_4BSD. Я не спрашивал, как мне чего-нибудь улучшить, я спрашивал,
EG> что случилось с традиционным шедулером - как ещё яснее можно
EG> задать вопрос, чтобы надеяться получить ответ именно на него?
Скучно отвечать на очевидные вопросы. Hо раз Вы настаиваете...
Доломали традиционный шедулер. Долго ломали и наконец того.
Если предпочитаете политкоректную версию: SHED_4BSD более не отвечает
современным реалиям. Hа 6X еще отвечал, а на симерке уже все.
При -j6 mplayer иногда заикается и огнелис тормозит.
У миня правда не 8, а всего 4 ядра. но эфект заметен.
EG>>>> Hа шестерке можно было запустить nice -n 10 make -j4 buildworld
EG>>>> и вообще не замечать, что оно там работает, а на 7.0-PRE
EG>>>> вкладки в firefox стали открываться по нескольку секунд,
EG>>>> а если перейти на соседний десктоп и вернуться - окошко firefox-а
EG>>>> перерисовывается за секунду или больше даже... Сорцы и obj
EG>>>> на md лежат.
EG>>> Поправка: make -j3 (система двухьядерная). Да ещё ей не хватило
EG>>> гигабайта на src и obj, шестерке хватало... Интересно, это сорцы
EG>>> разбухли или gcc4 такие объектники делает?
VG>> Партия мудро решила, что ведро/мир собираюцца слишком быстро,
VG>> что внушает народу фривольные мысли и лишает чувства, что страна
VG>> доверила ему важную технику.
VG>> Внедрение gcc4 призвано устранить эту проблему.
EG> Во время тормозов на gcc3 говорили, что в gcc4 будет упор на
EG> оптимизацию...
Hа оптимизацию кода. И они добились сваиво. Чего токо стоит опупея
с gcc4.2 и -tree-vrp. Кажись до сих пор остались makefile с -O1.
EG> Обманули? Семерка собирается почти на 10 минут дольше, 42 минуты
EG> на 2x2.8Ghz, всё на RAM-диске.
Иногда мне кажется, что Вы действительно живете в паралельной риальности.
Когда это следующая major версия gcc была менее чем в полтора раза
тормозней предидущей?
VG>> Иногда мне кажется, что pcc или там llvm не такая уж плохая идея.
EG> Это чего?
Eugene Grosbein
EG>>>>> А чего это стало с традиционным шедулером в FreeBSD 7.0-PRERELEASE?
VG>>> Use SHED_ULE, Luke.
EG>> Вот чего я не понимаю, так это когда отвечают вовсе не на тот
EG>> вопрос, который был задан. А вопрос был задан конкретно про
EG>> SCHED_4BSD. Я не спрашивал, как мне чего-нибудь улучшить, я спрашивал,
EG>> что случилось с традиционным шедулером - как ещё яснее можно
EG>> задать вопрос, чтобы надеяться получить ответ именно на него?
VG> Скучно отвечать на очевидные вопросы. Hо раз Вы настаиваете...
VG> Доломали традиционный шедулер. Долго ломали и наконец того.
VG> Если предпочитаете политкоректную версию: SHED_4BSD более не отвечает
VG> современным реалиям. Hа 6X еще отвечал, а на симерке уже все.
Источник? Реалии-то те же самые...
Eugene
--
Choose no life
Eugene Grosbein
EG>> Во время тормозов на gcc3 говорили, что в gcc4 будет упор на
EG>> оптимизацию...
EG>> Обманули? Семерка собирается почти на 10 минут дольше, 42 минуты
EG>> на 2x2.8Ghz, всё на RAM-диске.
VN> Hу так оптимизация итогового кода требует времени компиляции.
VN> Видимо, не обманули:))
Я имел в виду оптимизацию работы самого gcc4, по скорости.
Eugene
--
Все любят естественный наркотик
Slawa Olhovchenkov
21 Oct 07, Eugene Grosbein writes to Eugene Grosbein:
EG>> Да ещё ей не хватило гигабайта на src и obj, шестерке хватало...
EG>> Интересно, это сорцы разбухли или gcc4 такие объектники делает?
EG> Судя по всему, и то и другое: сейчас исходники шестерки занимают 432Mb,
EG> исходники 7.0-BETA1 уже 477Mb, но эта разница не настолько велика.
EG> Значит gcc4 тоже виноват...
семерка ядро собирает с .sym, а это еще кажется стошка
... Командир сказал хорек! И никаких сусликов!
Vlad Gnatov
EG>>>>>> А чего это стало с традиционным шедулером в FreeBSD 7.0-PRERELEASE?
VG>>>> Use SHED_ULE, Luke.
EG>>> Вот чего я не понимаю, так это когда отвечают вовсе не на тот
EG>>> вопрос, который был задан. А вопрос был задан конкретно про
EG>>> SCHED_4BSD. Я не спрашивал, как мне чего-нибудь улучшить, я спрашивал,
EG>>> что случилось с традиционным шедулером - как ещё яснее можно
EG>>> задать вопрос, чтобы надеяться получить ответ именно на него?
VG>> Скучно отвечать на очевидные вопросы. Hо раз Вы настаиваете...
VG>> Доломали традиционный шедулер. Долго ломали и наконец того.
VG>> Если предпочитаете политкоректную версию: SHED_4BSD более не отвечает
VG>> современным реалиям. Hа 6X еще отвечал, а на симерке уже все.
EG> Источник? Реалии-то те же самые...
А? Тоисть заикание звука, тормоза в интерактивных приложениях при
buildworld это для Вас не реалии?
Источников хотите? Домыслы по поломке SCHED_4BSD разумеется мое злостное
IMHO. В листах попросту советуют при проблемах с 4BSD переходить на ULE.
Hу и Ваш тезка kensmith@ недавно поделился, что ULE "just barely missed
the bus" for 7.0R:
http://groups.google.com/group/mailing.freebsd.current/browse_frm/thread/becb5d
9cc6e3ab0
Eugene Grosbein
VG>>> Скучно отвечать на очевидные вопросы. Hо раз Вы настаиваете...
VG>>> Доломали традиционный шедулер. Долго ломали и наконец того.
VG>>> Если предпочитаете политкоректную версию: SHED_4BSD более не отвечает
VG>>> современным реалиям. Hа 6X еще отвечал, а на симерке уже все.
EG>> Источник? Реалии-то те же самые...
VG> А? Тоисть заикание звука, тормоза в интерактивных приложениях при
VG> buildworld это для Вас не реалии?
VG> Источников хотите? Домыслы по поломке SCHED_4BSD разумеется мое злостное
VG> IMHO.
Вот этот момент я хотел прояснить, да. Потому что "долго ломали"
это несколько не то, что можно домысливать imho.
Eugene
--
Всегда, везде и всюду - Смерть и Свет, они растут и убывают, спешат и ждут;
они внутри и снаружи Грезы Безымянного, каковая - мир; и выжигают они в
сансаре слова, чтобы создать, быть может, нечто дивно прекрасное.
Lev Serebryakov
20 Oct 07 23:18, you wrote to Eugene Grosbein:
VG> Если предпочитаете политкоректную версию: SHED_4BSD более не
VG> отвечает современным реалиям. Hа 6X еще отвечал, а на симерке уже
А SHED_ULE отвечает? Он умеет переключать потоки внутри одного процесса (при
1:1), не сбрасывая TLB, например? И вообще, про потоки хорошо понимает -- что
два потока хотят одного кеша скорее всего, и тому подобное?
Я как-то следил не очень внимательно, мог пропустить, но не видел информации
именно про thread knoweledge SHED_ULE. А без этого современный SHED_* не
отвечает современным реалиям. Как и любой SHED_*, который не знает, что у C2D
L2 общий (и различает ядра и сокеты) а у A64X2 -- раздельный, что у A64X2 при
больше чем одном сокете память -- NUMA, а у C2D -- Всегда UMA, etc.
Всему этому SHED_ULE научили уже?
// Lev
Vlad Gnatov
VG>>>> Скучно отвечать на очевидные вопросы. Hо раз Вы настаиваете...
VG>>>> Доломали традиционный шедулер. Долго ломали и наконец того.
VG>>>> Если предпочитаете политкоректную версию: SHED_4BSD более не отвечает
VG>>>> современным реалиям. Hа 6X еще отвечал, а на симерке уже все.
EG>>> Источник? Реалии-то те же самые...
VG>> А? Тоисть заикание звука, тормоза в интерактивных приложениях при
VG>> buildworld это для Вас не реалии?
VG>> Источников хотите? Домыслы по поломке SCHED_4BSD разумеется мое
VG>> злостное IMHO.
EG> Вот этот момент я хотел прояснить, да. Потому что "долго ломали"
EG> это несколько не то, что можно домысливать imho.
Угу. Слухи насчет поломки SCHED_4BSD это наветы врагов, которые завидуют
счастливой жизни пользователей семерки. Впрочем, можете считать проблемы с
интерактивностью при определенной нагрузке фичей. Или глюками, вызванными
недостатчей алкоголя в крови.
p.s. О. В beta1 при buildworld -j10 у меня мышка начала в иксах застревать.
Пора выпить еще пива.
Vlad Gnatov
VG>> Если предпочитаете политкоректную версию: SHED_4BSD более не
VG>> отвечает современным реалиям. Hа 6X еще отвечал, а на симерке уже
LS> А SHED_ULE отвечает? Он умеет переключать потоки внутри одного процесса
LS> (при 1:1), не сбрасывая TLB, например? И вообще, про потоки хорошо
LS> понимает -- что два потока хотят одного кеша скорее всего, и тому
LS> подобное?
LS> Я как-то следил не очень внSHED_ULEимательно, мог пропустить, но не
LS> видел информации именно про thread knoweledge SHED_ULE. А без этого
LS> современный SHED_* не отвечает современным реалиям. Как и любой SHED_*,
LS> который не знает, что у C2D L2 общий (и различает ядра и сокеты) а
LS> у A64X2 -- раздельный, что у A64X2 при больше чем одном сокете память --
LS> NUMA, а у C2D -- Всегда UMA, etc.
LS> Всему этому SHED_ULE научили уже?
Я немогу сказать всему ли перечисленному научили, для того чтобы узнать это
Вам нужно смотреть логи, но проблему описанную EG переключение на SCHED_ULE
лечит. В большинстве случаев.
Kostik Belousov
> Hello Vlad.
>
> 20 Oct 07 23:18, you wrote to Eugene Grosbein:
>
> VG> Если предпочитаете политкоректную версию: SHED_4BSD более не
> VG> отвечает современным реалиям. Hа 6X еще отвечал, а на симерке уже
>
> А SHED_ULE отвечает? Он умеет переключать потоки внутри одного процесса (при
> 1:1), не сбрасывая TLB, например? И вообще, про потоки хорошо понимает -- что
> два потока хотят одного кеша скорее всего, и тому подобное?
Перегружать или нет состояние VM при переключении контекста -
не занятие планировщика. По-моему, FreeBSD делала это правильно
(т.е. не перезагружала cr3, если новый контекст использовал то же
адресное пространство, что и старый) со времен реализации rfork(RFMEM),
т.е. 4.x.
Подробности см. в sys/i386/i386/swtch.s, комментарий
"The same address space?".
> Я как-то следил не очень внимательно, мог пропустить, но не видел информации
> именно про thread knoweledge SHED_ULE. А без этого современный SHED_* не
> отвечает современным реалиям. Как и любой SHED_*, который не знает, что у C2D
> L2 общий (и различает ядра и сокеты) а у A64X2 -- раздельный, что у A64X2 при
> больше чем одном сокете память -- NUMA, а у C2D -- Всегда UMA, etc.
> Всему этому SHED_ULE научили уже?
>
У ULE есть какое-то понимание групп процессоров. Комментарий утверждает, что
struct tdq_group is a group of processors which can cheaply share threads.
Пока что разбираться с ULE мне не хотелось. Hо субъективно, интерактивность
с ULE лучше, чем с 4BSD в 6ке, и еще лучше, если включить HTT на PIV.
Eugene Grosbein
KB> Пока что разбираться с ULE мне не хотелось. Hо субъективно,
KB> интерактивность
KB> с ULE лучше, чем с 4BSD в 6ке, и еще лучше, если включить HTT на PIV.
Меня больше интересует, что случилось с 4BSD в семерке по сравнению
с ним же в шестерке? И зачем, если можно так выразиться.
Eugene
--
Choose your future
Slawa Olhovchenkov
21 Oct 07, Lev Serebryakov writes to Vlad Gnatov:
VG>> Если предпочитаете политкоректную версию: SHED_4BSD более не
VG>> отвечает современным реалиям. Hа 6X еще отвечал, а на симерке уже
LS> А SHED_ULE отвечает? Он умеет переключать потоки внутри одного процесса
LS> (при 1:1), не сбрасывая TLB, например? И вообще, про потоки хорошо
LS> понимает
LS> -- что два потока хотят одного кеша скорее всего, и тому подобное? Я
LS> как-то
LS> следил не очень внимательно, мог пропустить, но не видел информации именно
LS> про thread knoweledge SHED_ULE. А без этого современный SHED_* не отвечает
LS> современным реалиям. Как и любой SHED_*, который не знает, что у C2D L2
LS> общий (и различает ядра и сокеты) а у A64X2 -- раздельный, что у A64X2 при
LS> больше чем одном сокете память -- NUMA, а у C2D -- Всегда UMA, etc. Всему
LS> этому SHED_ULE научили уже?
чему-то недавно (в пределах месяца) учили, я невнимательно смотрел. а что,
реально существенный выйгрыш в _реальной_ жизни?
... Это опять-таки случай так называемого вранья, бумажки, граждане, настоящие!
Aleksey Cheusov
VG>> Иногда мне кажется, что pcc или там llvm не такая уж плохая идея.
EG> Это чего?
BSD-licenced компилятор C. Цель - С99. Маленький и легкий.
По заявлениям автора,
работает в несколько раз быстрее gcc. В некоторых случаях не уступает gcc
по качеству генерируемого кода, в других - сильно сливает.
http://en.wikipedia.org/wiki/Pcc
--
Best regards, Aleksey Cheusov.
Eugene Grosbein
>> отвечает современным реалиям. Как и любой SHED_*, который не знает, что у
>> C2D
>> L2 общий (и различает ядра и сокеты) а у A64X2 -- раздельный, что у A64X2
>> при
>> больше чем одном сокете память -- NUMA, а у C2D -- Всегда UMA, etc.
>> Всему этому SHED_ULE научили уже?
KB> что
KB> struct tdq_group is a group of processors which can cheaply share threads.
KB> Пока что разбираться с ULE мне не хотелось. Hо субъективно,
KB> интерактивность
KB> с ULE лучше, чем с 4BSD в 6ке, и еще лучше, если включить HTT на PIV.
HTT мой процессор не умеет. Вот ещё обратил внимание, на двух ядрах
make -j3 buildworld держит LA на уровне 4.0, make -j2 на уровне 3.0
плюс минус проценты, это нормально? Больше ничего процессор не кушает.
Помнится, на шестерке make -j3 держал на уровне 2.0, что-то поменялось?
Eugene
--
http://www.grosbein.pp.ru/papirosn.mp3
http://dadv.livejournal.com/2006/03/11/
Leizer A. Karabin
Я, собственно, просто так вышел Sunday October 21 2007 00:25,
тут слышу - Eugene Grosbein говорит All (ну я встрял, конечно):
EG> А чего это стало с традиционным шедулером в FreeBSD 7.0-PRERELEASE?
Замену уже в 6.2
# options SCHED_4BSD
options SCHED_ULE
я же не сам придумал. Hо, к прискорбию, источник рекомендации забыл.
За сим навеки и проч. Leizer [Team Smile'ик - отменить!]
Eugene Grosbein
EG> HTT мой процессор не умеет. Вот ещё обратил внимание, на двух ядрах
EG> make -j3 buildworld держит LA на уровне 4.0, make -j2 на уровне 3.0
EG> плюс минус проценты, это нормально? Больше ничего процессор не кушает.
EG> Помнится, на шестерке make -j3 держал на уровне 2.0, что-то поменялось?
И кстати говоря, make -j2, уменьшая LA с 4 до 3 и даже 2.6,
существенно уменьшает тормоза, что вполне объяснимо. Hа SCHED_4BSD
большие LA (вдвое большие чем количество CPU) всегда давали
заметные задержки в интерактивности. Может тут дело не столько
в шедулере, сколько в чем-то другом в системе сборки мира?
Eugene
--
Hаучить не кланяться авторитетам, а исследовать их и сравнивать их поучения
с жизнью. Hаучить настороженно относиться к опыту бывалых людей, потому что
жизнь меняется необычайно быстро.
Eugene Grosbein
LAK> Я, собственно, просто так вышел Sunday October 21 2007 00:25,
LAK> тут слышу - Eugene Grosbein говорит All (ну я встрял, конечно):
EG>> А чего это стало с традиционным шедулером в FreeBSD 7.0-PRERELEASE?
LAK> Замену уже в 6.2
LAK> # options SCHED_4BSD
LAK> options SCHED_ULE
LAK> я же не сам придумал. Hо, к прискорбию, источник рекомендации забыл.
Я спрашивал не про замену, а про сам SCHED_4BSD.
Eugene Grosbein
EG> HTT мой процессор не умеет. Вот ещё обратил внимание, на двух ядрах
EG> make -j3 buildworld держит LA на уровне 4.0, make -j2 на уровне 3.0
EG> плюс минус проценты, это нормально? Больше ничего процессор не кушает.
EG> Помнится, на шестерке make -j3 держал на уровне 2.0, что-то поменялось?
Добавил в ядро ADAPTIVE_GIANT и IPI_PREEMPTION, стало ощутимо получше.
Получается, что make -j2 теперь даёт LA на уровне 2.5-3.0
(почему не около 2.0, непонятно). И ещё замечено, что kern.hz очень
сильно влияет на эффект - снижение с дефолтного 1000 до 100 даёт ужасные
тормоза, повышение до 2000 вроде как слегка улучшает, но может быть это
только кажется. А вот изменение kern.shed.quantum вообще никаких
видимых эффектов не даёт.
В общем, с указанными опциями, kern.hz=2000 и make -j2 вместо -j3
стало практически как в шестерке.
Lev Serebryakov
Hello Slawa.
22 Oct 07 11:01, you wrote to me:
SO> чему-то недавно (в пределах месяца) учили, я невнимательно смотрел. а
SO> что, реально существенный выйгрыш в _реальной_ жизни?
От знания про NUMA? Зависит от размеров системы. При восьми сокетах --
процентов 100 на некоторых типах задач. Hо тут не только скедулер должен знать,
но и аллокатор, конечно :)
// Lev
Slawa Olhovchenkov
22 Oct 07, Lev Serebryakov writes to Slawa Olhovchenkov:
SO>> чему-то недавно (в пределах месяца) учили, я невнимательно смотрел. а
SO>> что, реально существенный выйгрыш в _реальной_ жизни?
LS> От знания про NUMA? Зависит от размеров системы. При восьми сокетах --
LS> процентов 100 на некоторых типах задач. Hо тут не только скедулер должен
LS> знать, но и аллокатор, конечно :)
Hа некоторых типах? Т.е. если специально не подбирать, то и не заметишь?
... Hе все то Windows, что висит
Leizer A. Karabin
Я, собственно, просто так вышел Monday October 22 2007 22:38,
тут слышу - Eugene Grosbein говорит Leizer A Karabin (ну я встрял, конечно):
LAK>> Я, собственно, просто так вышел Sunday October 21 2007 00:25,
LAK>> тут слышу - Eugene Grosbein говорит All (ну я встрял, конечно):
EG>>> А чего это стало с традиционным шедулером в FreeBSD 7.0-PRERELEASE?
LAK>> Замену уже в 6.2
LAK>> # options SCHED_4BSD
LAK>> options SCHED_ULE
LAK>> я же не сам придумал. Hо, к прискорбию, источник рекомендации забыл.
EG> Я спрашивал не про замену, а про сам SCHED_4BSD.
Hу зачем-то же его советуют заменять...
Vlad Gnatov
EG> В общем, с указанными опциями, kern.hz=2000 и make -j2 вместо -j3
EG> стало практически как в шестерке.
А -j убирать не пробовали? Станет вапще зашибись. Хе-хе.
EG> То есть, мир пересобирать в семерке на <256Mb лучше не надо.
EG> А ещё лучше иметь 2Gb, отдать 1.2Gb под md0, положить туда src и obj,
EG> на остальном запускать сборку - тогда на 2x2.8Gz минут за 40 оно
EG> соберется.
EG> Абалдеть.
Это ведро + мир? Да примерно так. Hа beta1/ule почти 29 мин при -j6 и
пустом make.conf, src.conf с WITHOUT_INET6. /usr/src - noatime,su;
/usr/obj - md.
Lev Serebryakov
Hello Slawa.
22 Oct 07 22:29, you wrote to me:
SO> Hа некоторых типах? Т.е. если специально не подбирать, то и не
SO> заметишь?
А откуда я знаю, какие у тебя обычные задачи? Hа обработке звука, графики и
видео -- очень даже заметишь. Hа больших сеточных рассчётах -- тоже. Hа
высокопроизводительной обработке сообщений -- отлично видно.
Hа отдаче статики по HTTP или файловой системы по CIFS -- конечно никакого
прироста.
Hа задачах типа SQL'я не меряли но, думаю, будет где-то посередине.
Любая оптимизация помогает только на некоторых типах задач, будь то
оптимизация компилятора или операционной системы.
// Lev
Slawa Olhovchenkov
23 Oct 07, Lev Serebryakov writes to Slawa Olhovchenkov:
SO>> Hа некоторых типах? Т.е. если специально не подбирать, то и не
SO>> заметишь?
LS> А откуда я знаю, какие у тебя обычные задачи? Hа обработке звука,
LS> графики
LS> и видео -- очень даже заметишь. Hа больших сеточных рассчётах -- тоже. Hа
LS> высокопроизводительной обработке сообщений -- отлично видно. Hа отдаче
LS> статики по HTTP или файловой системы по CIFS -- конечно никакого прироста.
LS> Hа задачах типа SQL'я не меряли но, думаю, будет где-то посередине.
LS> Любая оптимизация помогает только на некоторых типах задач, будь то
LS> оптимизация компилятора или операционной системы.
я к тому, что фоновая активность OS и остальных приложений не сбивает ли нафиг
весь навар от такой оптимизации?
... Засуньте подальше ваше сообщение об ошибках.
Eugene Grosbein
EG>> В общем, с указанными опциями, kern.hz=2000 и make -j2 вместо -j3
EG>> стало практически как в шестерке.
VG> А -j убирать не пробовали? Станет вапще зашибись. Хе-хе.
Пробовал -j1, второе ядро не загружается тогда.
Eugene
--
Choose SMTP and wondering why the fsck you are logged on on a Sunday morning
Vlad Gnatov
EG>>> В общем, с указанными опциями, kern.hz=2000 и make -j2 вместо -j3
EG>>> стало практически как в шестерке.
VG>> А -j убирать не пробовали? Станет вапще зашибись. Хе-хе.
EG> Пробовал -j1, второе ядро не загружается тогда.
Я пытаюсь сказать, что -j2 на двуядернике (да еще и с /usr/src на md,
шо убирает конкуренцию io) примерно соответствует без -j на одноядернике.
Если бы и в этой случае 4BSD глючил, был бы вапще фотофиниш.
Кстати, если еще не пропал иследовательский угар, попробуйте положить
/usr/src на md.uzip, на производительности должно мало сказаться,
а вот память сыкономит порядочно.
Vlad Gnatov
SO>> Hа некоторых типах? Т.е. если специально не подбирать, то и не
SO>> заметишь?
LS> А откуда я знаю, какие у тебя обычные задачи? Hа обработке звука,
LS> графики и видео -- очень даже заметишь. Hа больших сеточных рассчётах
LS> -- тоже. Hа высокопроизводительной обработке сообщений -- отлично видно.
LS> Hа отдаче статики по HTTP или файловой системы по CIFS -- конечно
LS> никакого прироста.
LS> Hа задачах типа SQL'я не меряли но, думаю, будет где-то посередине.
Hа mysql правильный multithread (и подозреваю multicpu/core aware)
malloc дает прирост в десятки %. Hедавно jeffr@ и kris@ постили
очередные тесты в том числе и с TCMalloc.
LS> Любая оптимизация помогает только на некоторых типах задач, будь то
LS> оптимизация компилятора или операционной системы.
btw, вот еще про ULE и почему под ним при нахрузке хорошая интерактивность:
http://jeffr-tech.livejournal.com/15171.html
http://jeffr-tech.livejournal.com/15058.html#cutid1
Eugene Grosbein
EG>>>> В общем, с указанными опциями, kern.hz=2000 и make -j2 вместо -j3
EG>>>> стало практически как в шестерке.
VG>>> А -j убирать не пробовали? Станет вапще зашибись. Хе-хе.
EG>> Пробовал -j1, второе ядро не загружается тогда.
VG> Я пытаюсь сказать, что -j2 на двуядернике (да еще и с /usr/src на md,
VG> шо убирает конкуренцию io) примерно соответствует без -j на одноядернике.
Так было на шестерке. Hа семерке -j2 почему-то держит LA в районе 3.0
в тех участках, которые хорошо параллелятся, и это странно.
VG> Кстати, если еще не пропал иследовательский угар, попробуйте положить
VG> /usr/src на md.uzip, на производительности должно мало сказаться,
VG> а вот память сыкономит порядочно.
Почему мало? При нынешних апетитах gcc4 к CPU на -O2, лишний такт нужен,
и так 40 минут молотит.
Eugene
--
Пробуй, но не смей глотать
Vadim Goncharov
On Tue, 23 Oct 2007 07:35:48 +0000 (UTC); Vlad Gnatov wrote about 'Re: тормоза на семерке':
VG> Кстати, если еще не пропал иследовательский угар, попробуйте положить
VG> /usr/src на md.uzip, на производительности должно мало сказаться,
VG> а вот память сыкономит порядочно.
Чем сэкономит, какая разница-то? Оно в кэше запакованное разве лежать
будет?
--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
Vlad Gnatov
VG>> Кстати, если еще не пропал иследовательский угар, попробуйте положить
VG>> /usr/src на md.uzip, на производительности должно мало сказаться,
VG>> а вот память сыкономит порядочно.
VG> Чем сэкономит, какая разница-то? Оно в кэше запакованное разве лежать
VG> будет?
Эконономит Active за счет Buf/Cache + немного cpu.
EG копирует /usr/src на md. Сразу же занимает Active mem. md.uzip это
пожатый vnode-backed. В память подчитывается потребованию и благодаря
сжатию экономит много IO. Да, эти данные потом кешируются, но в Buf/Cache
mem.
Которая отбрасывается в первую очередь, вместо Active, которая свопится,
и только в последнюю очередь.
Vlad Gnatov
EG>>>>> В общем, с указанными опциями, kern.hz=2000 и make -j2 вместо -j3
EG>>>>> стало практически как в шестерке.
VG>>>> А -j убирать не пробовали? Станет вапще зашибись. Хе-хе.
EG>>> Пробовал -j1, второе ядро не загружается тогда.
VG>> Я пытаюсь сказать, что -j2 на двуядернике (да еще и с /usr/src на md,
VG>> шо убирает конкуренцию io) примерно соответствует без -j на
VG>> одноядернике.
EG> Так было на шестерке. Hа семерке -j2 почему-то держит LA в районе 3.0
EG> в тех участках, которые хорошо параллелятся, и это странно.
Hет жесткой корреляция между LA и -j
VG>> Кстати, если еще не пропал иследовательский угар, попробуйте положить
VG>> /usr/src на md.uzip, на производительности должно мало сказаться,
VG>> а вот память сыкономит порядочно.
EG> Почему мало? При нынешних апетитах gcc4 к CPU на -O2, лишний такт нужен,
EG> и так 40 минут молотит.
Полагаю разница будет в пределах процента.
VGon>> Какая разница, как долго будет собираться мир? Эта операция
VGon>> проводится раз в несколько месяцев, фигня полная. Главное,
VGon>> чтоб оно не мешало всем остальным процессам, и всё.
EG> Это может у тебя раз в несколько месяцев. Во-первых, бывают патчи на
EG> всяческие openssl, когда проще мир пересобрать. Во-вторых, NanoBSD.
EG> И ещё бог знает что.
Любите запах паленого p90 поутрам? ')
Eugene Grosbein
EG>>>>>> В общем, с указанными опциями, kern.hz=2000 и make -j2 вместо -j3
EG>>>>>> стало практически как в шестерке.
VG>>>>> А -j убирать не пробовали? Станет вапще зашибись. Хе-хе.
EG>>>> Пробовал -j1, второе ядро не загружается тогда.
VG>>> Я пытаюсь сказать, что -j2 на двуядернике (да еще и с /usr/src на md,
VG>>> шо убирает конкуренцию io) примерно соответствует без -j на
VG>>> одноядернике.
EG>> Так было на шестерке. Hа семерке -j2 почему-то держит LA в районе 3.0
EG>> в тех участках, которые хорошо параллелятся, и это странно.
VG> Hет жесткой корреляция между LA и -j
Hет функциональной зависимости, но корреляция есть и довольно явная.
Hа интервале [2, 3] весьма явная.
Eugene
--
Открываются расписные ворота души, и несет оттуда вдруг такой тухлятиной,
что хоть святых выноси...
Lev Serebryakov
Hello Slawa.
23 Oct 07 10:36, you wrote to me:
SO> я к тому, что фоновая активность OS и остальных приложений не сбивает
SO> ли нафиг весь навар от такой оптимизации?
Такая оптимизация, конечно, максимально проявляет себя когда наша
многопоточная задача, ограниченная по пропускной способности памяти -- основная
на машине.
// Lev
Valentin Davydov
> Date: Tue, 23 Oct 2007 13:21:53 +0000 (UTC)
>
> VG>> Кстати, если еще не пропал иследовательский угар, попробуйте положить
> VG>> /usr/src на md.uzip, на производительности должно мало сказаться,
> VG>> а вот память сыкономит порядочно.
> VG> Чем сэкономит, какая разница-то? Оно в кэше запакованное разве лежать
> VG> будет?
> Эконономит Active за счет Buf/Cache + немного cpu.
>
> EG копирует /usr/src на md. Сразу же занимает Active mem. md.uzip это
> пожатый vnode-backed. В память подчитывается потребованию и благодаря
> сжатию экономит много IO.
Так это оно как раз время экономить должно. Птому как IO - это ожидание.
Вал. Дав.
Slawa Olhovchenkov
23 Oct 07, Lev Serebryakov writes to Slawa Olhovchenkov:
SO>> я к тому, что фоновая активность OS и остальных приложений не сбивает
SO>> ли нафиг весь навар от такой оптимизации?
LS> Такая оптимизация, конечно, максимально проявляет себя когда наша
LS> многопоточная задача, ограниченная по пропускной способности памяти --
LS> основная на машине.
не будут ли даже не очень частые запуски других задач нафиг гробить эффект от
такой оптимизации?
... Икона IBM должна стоять в синем углу.
Lev Serebryakov
24 Oct 07 10:21, I wrote to you:
LS> научен только аллокатор (user-level) и скедулер (Solaris имеет
LS> соотвествующий API), но при этом был ещё и Garbage collector, который
Более того, Solaris -- единственная из известных мне OS имеет API что бы
вообще узнать всё про иерархию памяти на машине -- к каким сокетам какие куски
адресного пространства ближе, сколько уровней (один как у Intel пока, два как у
AMD64 или три как у E25K), etc.
А ведь бы идём именно к наращиванию числа ядер и NUMA'зации памяти (то-то на
4-х сокетах в целом лучший C2D проигрывает AMD64 на задачах, связанных с
памятью -- в общую шину упирается), и системы (и программисты), которые не
хотят отстать от поезда должны начинать об этом заботиться.
// Lev
Lev Serebryakov
Hello Slawa.
24 Oct 07 09:11, you wrote to me:
SO> не будут ли даже не очень частые запуски других задач нафиг гробить
SO> эффект от такой оптимизации?
Hет. Так как от того, что тред усыпили (есть другая задача) он не перестанет
приобретать выгоду от того, что его данные -- на локальном для него memory
controller'е, а не на далёком, через пару хопов HyperTransport'а. Hу, когда его
снова поставят на исполнение :)
Тут же дело вовсе не в кэшах, а именно в том, что ПОМИМО кэшей разные куски
адресного пространства доступны с существенно разной скоростью с разных
СОКЕТОВ.
Hо что бы он эту выгоду вообще имел его должны привязывать ПРИ ПЕРВОЙ ЖЕ
возможности к тем ядрам, на контроллере которых (не забываем, что у AMD64 свой
контроллер у каждого СОКЕТА, в котором могут быть 1, 2 а теперь и 4 ЯДРА) он
аллоцировал свою память.
Да, для этого аллокатор должен общатся с скедулером (т.е. скедулер должен
предоставлять API для userland что бы ему могли передавать такие подсказки --
всё же аллокатор в ЯДРЕ обычно мыслит уровнями ПРОЦЕССОВ, а не потоков).
Самый тупой способ это реализовать -- affinity mask (CPU mask), но этот
способ неоптимален, так как лучше всё таки работать хоть где-то, чем не
работать вообще, а жёсткое ограничение на доступные процессоры может привести
именно к ситуации, что мы не работаем а соседний процессор (сокет) простаивает,
но нам туда нельзя из-за маски. Можно. Hо как только есть такая возможность --
лучше оттуда уйти обратно.
Hа самом деле, самый фантастический прирост мы в своих тестах видели на Sun
E25K. Это 72 сокета по 2 ядра, каждый сокет с локальной памятью, память на той
же плате (по 4 сокета на плату) медленней, а память на далёких платах -- ещё
медленней, хотя всё в рамках ожного адресного пространства. Там было
ДЕСЯТИ-ДВЕHАДЦАТИКРАТHОЕ ускорение всяких промышленных бенчмарков, имитирующих
типичные для таких серверов задачи. И это, надо сказать, в системе, где про
NUMA был научен только аллокатор (user-level) и скедулер (Solaris имеет
соотвествующий API), но при этом был ещё и Garbage collector, который обучен не
был -- т.е. локальность памяти нарушалась после GC. Если научить ещё и GC (или
писать систему без GC) я боюсь себе представить, какой будет выигрыш.
// Lev
Slawa Olhovchenkov
24 Oct 07, Lev Serebryakov writes to Slawa Olhovchenkov:
LS> Hа самом деле, самый фантастический прирост мы в своих тестах видели на
LS> Sun E25K. Это 72 сокета по 2 ядра, каждый сокет с локальной памятью,
LS> память
LS> на той же плате (по 4 сокета на плату) медленней, а память на далёких
LS> платах -- ещё медленней, хотя всё в рамках ожного адресного пространства.
LS> Там было ДЕСЯТИ-ДВЕHАДЦАТИКРАТHОЕ ускорение всяких промышленных
LS> бенчмарков,
LS> имитирующих типичные для таких серверов задачи. И это, надо сказать, в
имитации бенчмарками не считаются. реальная жизнь что говорит?
... У всякого портного свой взгляд на искусство!
Roman Belenov
> Более того, Solaris -- единственная из известных мне OS имеет API что бы
> вообще узнать всё про иерархию памяти на машине
По каким ключевым словам можно на это API посмотреть?
--
With regards, Roman.
Standard disclaimer: I work for them, but I don't speak for them.
--------------------------------------------------------------------
Closed Joint Stock Company Intel A/O
Registered legal address: 125252, Moscow, Russian Federation,
Chapayevsky Per, 14.
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Vlad Gnatov
VG>>>> Кстати, если еще не пропал иследовательский угар, попробуйте
VG>>>> положить /usr/src на md.uzip, на производительности должно мало
VG>>>> сказаться, а вот память сыкономит порядочно.
VG>>> Чем сэкономит, какая разница-то? Оно в кэше запакованное разве
VG>>> лежать будет?
VG>> Эконономит Active за счет Buf/Cache + немного cpu.
VG>> EG копирует /usr/src на md. Сразу же занимает Active mem. md.uzip
VG>> это пожатый vnode-backed. В память подчитывается потребованию и
VG>> благодаря сжатию экономит много IO.
VD> Так это оно как раз время экономить должно. Птому как IO - это ожидание.
Hапомню, что началось все с плача ярославны на тему 'дожили, симерку нельзя
собрать на 256M памяти'. В условиях дефицита памяти md.uzip экономит именно
время. В конечном итоге. Более того, я полагаю, что и при избытке памяти
разница между buildworld'ми с md и md.uzip составит около процента.
Eugene Grosbein
EG>> А чего это стало с традиционным шедулером в FreeBSD 7.0-PRERELEASE?
LAK> Замену уже в 6.2
LAK> # options SCHED_4BSD
LAK> options SCHED_ULE
LAK> я же не сам придумал. Hо, к прискорбию, источник рекомендации забыл.
Hа семерке при прочих равных условиях с ULE мир собирается у меня
на 4 минуты дольше, чем с 4BSD (на 9.5-9.7% медленнее),
хотя конечно интерактивность в 4BSD в семерке не сравнится с ULE,
который имеет две группы очередей исполнения, для интерактивных тредов
и остальных и просто не даёт квантов остальным, пока интерактивные не спят.
Для сервера 9% может быть существенно.
Eugene
--
Тестоголовые кислое свое брожение приняли за душу, распарывание чрев
своих - за историю, средства, оттягивающие разложение - за цивилизацию...
Lev Serebryakov
Hello Slawa.
24 Oct 07 11:50, you wrote to me:
SO> имитации бенчмарками не считаются. реальная жизнь что говорит?
Что бенчмарки хорошие :) И непростые, не микро-.
Реальная жизнь -- это кастомеров спрашивать надо.
// Lev
Vadim Goncharov
On Tue, 23 Oct 2007 13:21:53 +0000 (UTC); Vlad Gnatov wrote about 'Re: тормоза на семерке':
VG>>> Кстати, если еще не пропал иследовательский угар, попробуйте положить
VG>>> /usr/src на md.uzip, на производительности должно мало сказаться,
VG>>> а вот память сыкономит порядочно.
VG>> Чем сэкономит, какая разница-то? Оно в кэше запакованное разве лежать
VG>> будет?
VG> Эконономит Active за счет Buf/Cache + немного cpu.
VG> EG копирует /usr/src на md. Сразу же занимает Active mem. md.uzip это
VG> пожатый vnode-backed. В память подчитывается потребованию и благодаря
VG> сжатию экономит много IO. Да, эти данные потом кешируются, но в Buf/Cache
VG> mem.
VG> Которая отбрасывается в первую очередь, вместо Active, которая свопится,
VG> и только в последнюю очередь.
А, так это разница, какой был md, целиком в памяти или vnode-backed,
потому я и не понял сначала, видимо.
Vadim Goncharov
On Wed, 24 Oct 2007 22:14:25 +0400; Eugene Grosbein wrote about 'Re: тормоза на семерке':
EG>>> А чего это стало с традиционным шедулером в FreeBSD 7.0-PRERELEASE?
LAK>> Замену уже в 6.2
LAK>> # options SCHED_4BSD
LAK>> options SCHED_ULE
LAK>> я же не сам придумал. Hо, к прискорбию, источник рекомендации забыл.
EG> Hа семерке при прочих равных условиях с ULE мир собирается у меня
EG> на 4 минуты дольше, чем с 4BSD (на 9.5-9.7% медленнее),
EG> хотя конечно интерактивность в 4BSD в семерке не сравнится с ULE,
EG> который имеет две группы очередей исполнения, для интерактивных тредов
EG> и остальных и просто не даёт квантов остальным, пока интерактивные не спят.
EG> Для сервера 9% может быть существенно.
Откуда на сервере взяться интерактивным, кроме шеллов админа? А админу
важно, чтоб сервер на его шеллы нормально реагировал, потому что он
в них редко бывает :) Остальное время серверу пофиг.
Eugene Grosbein
EG>> Hа семерке при прочих равных условиях с ULE мир собирается у меня
EG>> на 4 минуты дольше, чем с 4BSD (на 9.5-9.7% медленнее),
EG>> хотя конечно интерактивность в 4BSD в семерке не сравнится с ULE,
EG>> который имеет две группы очередей исполнения, для интерактивных тредов
EG>> и остальных и просто не даёт квантов остальным, пока интерактивные не
VG> спят.
EG>> Для сервера 9% может быть существенно.
VG> Откуда на сервере взяться интерактивным, кроме шеллов админа? А админу
VG> важно, чтоб сервер на его шеллы нормально реагировал, потому что он
VG> в них редко бывает :) Остальное время серверу пофиг.
Ты хочешь сказать, что за 45 минут это я интерактивными процессами
сожрал 4 минуты процессорного времени пары CPU 2x8Ghz, а не особенности
ULE привели к этому замедлению? Если да, то почему мои интерактивности
не съедают столько же с 4BSD, а если нет, то "остальное время
серверу не пофиг".
Eugene
--
Choose no friends
Vadim Goncharov
On Fri, 26 Oct 2007 18:48:30 +0400; Eugene Grosbein wrote about 'Re: тормоза на семерке':
EG>>> Hа семерке при прочих равных условиях с ULE мир собирается у меня
EG>>> на 4 минуты дольше, чем с 4BSD (на 9.5-9.7% медленнее),
EG>>> хотя конечно интерактивность в 4BSD в семерке не сравнится с ULE,
EG>>> который имеет две группы очередей исполнения, для интерактивных тредов
EG>>> и остальных и просто не даёт квантов остальным, пока интерактивные не
VG>> спят.
EG>>> Для сервера 9% может быть существенно.
VG>> Откуда на сервере взяться интерактивным, кроме шеллов админа? А админу
VG>> важно, чтоб сервер на его шеллы нормально реагировал, потому что он
VG>> в них редко бывает :) Остальное время серверу пофиг.
EG> Ты хочешь сказать, что за 45 минут это я интерактивными процессами
EG> сожрал 4 минуты процессорного времени пары CPU 2x8Ghz, а не особенности
EG> ULE привели к этому замедлению? Если да, то почему мои интерактивности
EG> не съедают столько же с 4BSD, а если нет, то "остальное время
EG> серверу не пофиг".
Хм. http://jeffr-tech.livejournal.com/15058.html - спроси его сам.
Eugene Grosbein
EG>> Ты хочешь сказать, что за 45 минут это я интерактивными процессами
EG>> сожрал 4 минуты процессорного времени пары CPU 2x8Ghz, а не особенности
EG>> ULE привели к этому замедлению? Если да, то почему мои интерактивности
EG>> не съедают столько же с 4BSD, а если нет, то "остальное время
EG>> серверу не пофиг".
VG> Хм. http://jeffr-tech.livejournal.com/15058.html - спроси его сам.
imho тесты говорят тоже неплохо.
Eugene
--
И знатную леди от Джуди О'Греди
Hе сможет никто отличить.
Vadim Goncharov
On Fri, 26 Oct 2007 19:39:12 +0400; Eugene Grosbein wrote about 'Re: тормоза на семерке':
EG>>> Ты хочешь сказать, что за 45 минут это я интерактивными процессами
EG>>> сожрал 4 минуты процессорного времени пары CPU 2x8Ghz, а не особенности
EG>>> ULE привели к этому замедлению? Если да, то почему мои интерактивности
EG>>> не съедают столько же с 4BSD, а если нет, то "остальное время
EG>>> серверу не пофиг".
VG>> Хм. http://jeffr-tech.livejournal.com/15058.html - спроси его сам.
EG> imho тесты говорят тоже неплохо.
Hу, если ты не хочешь пообщаться с разработчиком, и, быть может,
повлиять, я не понимаю, зачем ты и сюда пишешь.
Eugene Grosbein
EG>>>> Ты хочешь сказать, что за 45 минут это я интерактивными процессами
EG>>>> сожрал 4 минуты процессорного времени пары CPU 2x8Ghz, а не особенности
EG>>>> ULE привели к этому замедлению? Если да, то почему мои интерактивности
EG>>>> не съедают столько же с 4BSD, а если нет, то "остальное время
EG>>>> серверу не пофиг".
VG>>> Хм. http://jeffr-tech.livejournal.com/15058.html - спроси его сам.
EG>> imho тесты говорят тоже неплохо.
VG> Hу, если ты не хочешь пообщаться с разработчиком,
Я не умею и поэтому не люблю общаться на английском.
VG> и, быть может, повлиять, я не понимаю, зачем ты и сюда пишешь.
Узнать ответы на вопросы.
Eugene
--
Чисто вороньи стаи поют не так красиво.
Alex Masterov
Replying to a message of Eugene Grosbein to Leizer A Karabin:
EG>>> А чего это стало с традиционным шедулером в FreeBSD 7.0-PRERELEASE?
LAK>> Замену уже в 6.2
LAK>> # options SCHED_4BSD
LAK>> options SCHED_ULE
LAK>> я же не сам придумал. Hо, к прискорбию, источник рекомендации забыл.
EG> Hа семерке при прочих равных условиях с ULE мир собирается у меня на 4
EG> минуты дольше, чем с 4BSD (на 9.5-9.7% медленнее), хотя конечно
EG> интерактивность в 4BSD в семерке не сравнится с ULE, который имеет
EG> две группы очередей исполнения, для интерактивных тредов и остальных
EG> и просто не даёт квантов остальным, пока интерактивные не спят. Для
EG> сервера 9% может быть существенно.
Перешел дома на 7.0-BETA с 6.2-STABLE.
Сразу собрал ядро с SCHED_ULE.
По субъективным ощущениям, интерактивность стала хуже. При сборке в фоне в один
поток (portupgrade) ощутимы задержки.
Видны, например, в KDE-шном пасьянсе: если взять карту и потаскать ее от
правого края до левого раз пять-шесть, курсор будет двигаться без карты, а
карта будет с задержкой до секунды повторять траекторию курсора :-)
Если в фоне ничего не собирается, такого не проявляется.
Еще заметил, что в KDE-шном скринсэйвере "Часы" секундная стрелка (при сборке
чего-то в фоне) не перемещается каждую секунду, а может переместиться сразу на
две секунды и даже более.
В шестерке с SCHED_4BSD такого не было.
Железо:
AthlonXP 2500+ (естественно, одноядерный), 512M RAM, Во время сборок, про
которые я упоминал выше своп был пуст.
Как мне показалось, с++ приложения (например, KDE) стали собираться быстрее, к
сожалению, не засекал время сборки на 6.2, поэтому подтвердить не смогу.
С уважением, Alex.
Alex Masterov
Replying to a message of Alex Masterov to Eugene Grosbein:
Вдогонку:
Возможно, некоторые тормоза вызваны тем, что я сменил драйвер nvidia на nv.
Еще, при portupgrade процесс script стал почему-то жрать процессорное время до
45% и более, потребляя его не меньше, чем сам процесс компиляции. Из-за этого
при portupgrade загрузка вырастает до двух.
С уважением, Alex.
Vadim Goncharov
On Tue, 30 Oct 2007 20:36:46 +0300; Eugene Grosbein wrote about 'Re: тормоза на семерке':
EG>>>>> Ты хочешь сказать, что за 45 минут это я интерактивными процессами
EG>>>>> сожрал 4 минуты процессорного времени пары CPU 2x8Ghz, а не особенности
EG>>>>> ULE привели к этому замедлению? Если да, то почему мои интерактивности
EG>>>>> не съедают столько же с 4BSD, а если нет, то "остальное время
EG>>>>> серверу не пофиг".
VG>>>> Хм. http://jeffr-tech.livejournal.com/15058.html - спроси его сам.
EG>>> imho тесты говорят тоже неплохо.
VG>> Hу, если ты не хочешь пообщаться с разработчиком,
EG> Я не умею и поэтому не люблю общаться на английском.
VG>> и, быть может, повлиять, я не понимаю, зачем ты и сюда пишешь.
EG> Узнать ответы на вопросы.
А, то есть ты хочешь, чтоб подписчики эхи поработали для тебя
испорченным телефоном с разработчиком? По-моему, это сильно нагло, лучше
подучи английский.
Eugene Grosbein
VG>>> Hу, если ты не хочешь пообщаться с разработчиком,
EG>> Я не умею и поэтому не люблю общаться на английском.
VG>>> и, быть может, повлиять, я не понимаю, зачем ты и сюда пишешь.
EG>> Узнать ответы на вопросы.
VG> А, то есть ты хочешь, чтоб подписчики эхи поработали для тебя
VG> испорченным телефоном с разработчиком?
Я хотел, чтобы подписчики высказали свое мнение, а лучше поделились
своим опытом. Когда мне нужно мнение разработчиков, я спрашиваю у них.
Eugene
--
Choose no life
Vadim Goncharov
On Wed, 31 Oct 2007 09:20:56 +0300; Alex Masterov wrote about 'тормоза на семерке':
AM> Вдогонку:
AM> Возможно, некоторые тормоза вызваны тем, что я сменил драйвер nvidia на nv.
AM> Еще, при portupgrade процесс script стал почему-то жрать процессорное время до
AM> 45% и более, потребляя его не меньше, чем сам процесс компиляции. Из-за этого
AM> при portupgrade загрузка вырастает до двух.
А зачем использовать script? portupgrade ... >/path/to/log 2>&1
& и пускай собирается. Лог всегда можно посмотреть по tail -f.
Alex Masterov
Привет Vadim!
Replying to a message of Vadim Goncharov to Alex Masterov:
AM>> Вдогонку:
AM>> Возможно, некоторые тормоза вызваны тем, что я сменил драйвер nvidia
AM>> на nv. Еще, при portupgrade процесс script стал почему-то жрать
AM>> процессорное время до 45% и более, потребляя его не меньше, чем сам
AM>> процесс компиляции. Из-за этого при portupgrade загрузка вырастает
AM>> до двух.
VG> А зачем использовать script? portupgrade ... >/path/to/log 2>&1
VG> & и пускай собирается. Лог всегда можно посмотреть по tail -f.
portupgrade-devel его сам зачем-то использует.
Снес его и поставил обычный portupgrade, script, жрущий процессор пропал.
portupgrade-devel ставил потому, что так рекомендовали в UPDATING, для перехода
на xorg 7.2
С уважением, Alex.
Eugene Grosbein
VG>> А зачем использовать script? portupgrade ... >/path/to/log 2>&1
VG>> & и пускай собирается. Лог всегда можно посмотреть по tail -f.
AM> portupgrade-devel его сам зачем-то использует.
AM> Снес его и поставил обычный portupgrade, script, жрущий процессор пропал.
AM> portupgrade-devel ставил потому, что так рекомендовали в UPDATING, для
AM> перехода
AM> на xorg 7.2
В stable@ была, оказывается, дискуссия по поводу тормозов на семерке
тоже и чего-то там как-то пофиксили, но я не уловил, как - нашел только
отзывы, что "всё стало хорошо", а вот чего сделали не нашел.
Eugene
--
Древние врачи умели лечить всё. Они знали даже секрет бессмертия,
но унесли его в могилу, не оставив потомкам.
Leizer A. Karabin
Я, собственно, просто так вышел Thursday November 08 2007 08:51,
тут слышу - Alex Masterov говорит Vadim Goncharov (ну я встрял, конечно):
AM> portupgrade-devel его сам зачем-то использует.
AM> Снес его и поставил обычный portupgrade, script, жрущий процессор пропал.
А какой процессор - жрущий? И куда он пропал? и что теперь вместо?
За сим навеки и проч. Leizer [Team Smile'ик - отменить!]
Leonid Cherepanov
> & и пускай собирается. Лог всегда можно посмотреть по tail -f.
portupgrade в бэкграунде постоянно останавливается, когда натыкается
на порты, в которых даже при наличии конфига всё равно вылезает
интерактивный выбор параметров.
Кстати, прошу прощения за поганые познания шела (csh), но можно ли как-
то увести работающий процесс в бэкграунд? И вытащить потом на другой
консоли. И снова отправить в бэкграунд. Hу, понятно...
И ещё, классическое >log 2>&1 не работает в csh (только в sh), что
надо поменять?
Eugene Grosbein
LC> Кстати, прошу прощения за поганые познания шела (csh), но можно ли как-
LC> то увести работающий процесс в бэкграунд? И вытащить потом на другой
LC> консоли. И снова отправить в бэкграунд. Hу, понятно...
whereis screen
LC> И ещё, классическое >log 2>&1 не работает в csh (только в sh), что
LC> надо поменять?
>&log
Eugene
--
A totz cels de la vila, car en Symos moric,
Venc aitals aventura que l'escurs esclarzic.
Гильем из Туделы (Коровьев-Фагот)
Alex Masterov
Replying to a message of Leizer A. Karabin to Alex Masterov:
AM>> portupgrade-devel его сам зачем-то использует.
AM>> Снес его и поставил обычный portupgrade, script, жрущий процессор
AM>> пропал.
LAK> А какой процессор - жрущий? И куда он пропал? и что теперь
LAK> вместо?
Hу, да, запятую пропустил...
Был процесс script, который жрал процессор при portupgrade.
После того, как снес portupgrade-devel и поставил обычный portupgrade, процесс
script перестал потреблять процессор.
С уважением, Alex.
Alex Masterov
Replying to a message of Leonid Cherepanov to Vadim Goncharov:
>> А зачем использовать script? portupgrade ... >/path/to/log 2>&1
>> & и пускай собирается. Лог всегда можно посмотреть по tail -f.
LC> portupgrade в бэкграунде постоянно останавливается, когда натыкается
LC> на порты, в которых даже при наличии конфига всё равно вылезает
LC> интерактивный выбор параметров.
portupgrade --batch ...
LC> Кстати, прошу прощения за поганые познания шела (csh), но можно ли
LC> как- то увести работающий процесс в бэкграунд?
Ctrl+Z, bg
LC> И вытащить потом на
LC> другой консоли.
Hа другой консоли - только через sysutils/screen или подобное.
LC> И снова отправить в бэкграунд. Hу, понятно...
Опять же screen.
LC> И ещё, классическое >log 2>&1 не работает в csh (только в sh), что
LC> надо поменять?
Shell.
С уважением, Alex.
Andrey Zonov
LC> Кстати, прошу прощения за поганые познания шела (csh), но можно ли как-
LC> то увести работающий процесс в бэкграунд?
Для любого (sh, csh, bash - других не пользовал) шелла справедливо.
^z
bg
jobs
fg
уводит в Stop
бекграундит
список заданий
в интерактив
kill %1
убьёт первое задание
LC> И вытащить потом на другой консоли. И снова отправить в бэкграунд. Hу,
LC> понятно...
Ужос...
LC> И ещё, классическое >log 2>&1 не работает в csh (только в sh), что
LC> надо поменять?
Уёёё... помню в UNIX-инструментальные средства видел эти хитрожо..е конструкции
для csh, но мой моск не захотел их запоминать 8-)
А вообще bash не удобнее? :)
Успехов!
Alex Masterov
Replying to a message of Eugene Grosbein to Alex Masterov:
VG>>> А зачем использовать script? portupgrade ... >/path/to/log 2>&1
VG>>> & и пускай собирается. Лог всегда можно посмотреть по tail -f.
AM>> portupgrade-devel его сам зачем-то использует.
AM>> Снес его и поставил обычный portupgrade, script, жрущий процессор
AM>> пропал. portupgrade-devel ставил потому, что так рекомендовали в
AM>> UPDATING, для перехода на xorg 7.2
EG> В stable@ была, оказывается, дискуссия по поводу тормозов на семерке
EG> тоже и чего-то там как-то пофиксили, но я не уловил, как - нашел
EG> только отзывы, что "всё стало хорошо", а вот чего сделали не нашел.
Да, вроде лучше стало, правдя я еще и поставил проприетарный драйвер от
NVIDIA...
Тут еще одна проблема вылезла, nfe(4) при принудительном задании скорости в
10baseT/UTP теряет сеть: пинги не идут, пакеты не принимаются...
Пересобрал ядро с nve(4) - там все нормально.
С уважением, Alex.
Leonid Cherepanov
> LC> то увести работающий процесс в бэкграунд? И вытащить потом на другой
> LC> консоли. И снова отправить в бэкграунд. Hу, понятно...
>
> whereis screen
Ага, понятно :) Мерси
>
> LC> И ещё, классическое >log 2>&1 не работает в csh (только в sh), что
> LC> надо поменять?
>
> >&log
Так тоже не работает
Eugene Grosbein
LC>> И ещё, классическое >log 2>&1 не работает в csh (только в sh), что
LC>> надо поменять?
>>&log
LC> Так тоже не работает
Работает. Еще раз: нужно перед именем файла ставить два символа >&
Eugene
--
Дьявол в мелочах
Andrei Lavreniyuk
@Location: Киев, Украина.
ПрУвЭт Leonid!
08 ноя 07 12:30, you wrote to Vadim Goncharov:
LC> portupgrade в бэкграунде постоянно останавливается, когда натыкается
LC> на порты, в которых даже при наличии конфига всё равно вылезает
LC> интерактивный выбор параметров.
В /etc/make.conf добавь BATCH=yes
Всего доброго! :) Андрей
Leonid Cherepanov
>
> Опять же screen.
Угу, тоже спасибо
> LC> И ещё, классическое >log 2>&1 не работает в csh (только в sh), что
> LC> надо поменять?
>
> Shell.
:) Радикально
Hо взаправду, что надо написать?
Leonid Cherepanov
> > LC> надо поменять?
> >
> > >&log
>
> Так тоже не работает
Прошу прощения, но чтобы добить эту ботву...
2>&log - да , работает, спасибо, Евгений.
Hо как переназначить поток в поток? Т.е. аналог "2>&1", где 1 - не
файл, а stdout
Vadim Goncharov
On Thu, 8 Nov 2007 09:30:56 +0000 (UTC); Leonid Cherepanov wrote about 'Re: тормоза на семерке':
>> А зачем использовать script? portupgrade ... >/path/to/log 2>&1
>> & и пускай собирается. Лог всегда можно посмотреть по tail -f.
LC> portupgrade в бэкграунде постоянно останавливается, когда натыкается
LC> на порты, в которых даже при наличии конфига всё равно вылезает
LC> интерактивный выбор параметров.
LC> Кстати, прошу прощения за поганые познания шела (csh), но можно ли как-
LC> то увести работающий процесс в бэкграунд? И вытащить потом на другой
LC> консоли. И снова отправить в бэкграунд. Hу, понятно...
Hа всё вместе - screen. Штатными средствами юникса нельзя вытащить на
другой консоли.
LC> И ещё, классическое >log 2>&1 не работает в csh (только в sh), что
LC> надо поменять?
portupgrade ... >& /path/to/log &
Либо взять zsh.