| 1.1, pavlinux (ok), 23:39, 09/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
 В общем, Фроникс даже не фкурил для чего это нужно...
Давай какой-то NAS бенчмарк гонять, сборку ГрафиксМэджик :)
Это нужно для ВИРТУАЛОК!!! Для Многа Виртуалок!!! 500 - 1000 ...
А для приложений это ахтунг, точнее ахтунг для системы.
Вот представим сервак, например Апачь с 16000 тредов.
16000*2M ~= 31.25 Гиг, только для того чтоб запустить столько тредов.
Прикиньте, даже маленький мямлик (memleak) на 4*PAGE_SIZE, хрясь и 8 мегов нету :)
---
Блин, ща прикручу этот и SCHED_AUTOGROUP патчу...
Устроим тотальный ДОС make -j 1024 :)
| | |
| |
| 2.2, Sylvia (ok), 23:55, 09/12/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
 у них стандартный бенчмарк, на все случаи жизни :)
вот если бы патч оказывал негативное влияние на общую производительность системы в каком-либо из их тестов, то они бы конечно это в критику включили ) а специфических тестов от них редко удается дождаться, это же фороникс
| | |
| 2.7, pavlinux (ok), 01:34, 10/12/2010 [^] [^^] [^^^] [ответить]
| +6 +/– |
> Блин, ща прикручу этот и SCHED_AUTOGROUP патчу...
> Устроим тотальный ДОС make -j 1024 :)
Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!!!
---
% Чем меньше числа, тем лучше.
%
% Чистый malloc
%
# ./hgpages-bench
memset page fault 2942812
memset tlb miss 593223
memset second tlb miss 594958
random access tlb miss 33961
random access second tlb miss 33964
% Тут с библиотекой для работы с огромными страницами.
% и примонтированной hugetlbfs
% В конфиге ядра должно быть CONFIG_HUGETLBFS=y
%
# mkdir /hugetlb
# mount -t hugetlbfs hugetlbfs /hugetlb
# LD_PRELOAD=/usr/lib64/libhugetlbfs.so HUGETLB_MORECORE=yes HUGETLB_PATH=/hugetlb ./hgpages-bench
memset page fault 2964555
memset tlb miss 593843
memset second tlb miss 595469
random access tlb miss 33938
random access second tlb miss 33927
Это уже с Transparent Hugepage
# ./hgpages-bench
memset page fault 2009965
memset tlb miss 565256
memset second tlb miss 566410
random access tlb miss 18413
random access second tlb miss 18458
----
FILES:
Бенчмарк: - http://pavlinux.ru/hgpages/hgpage-bench.c
Патч: (Transparent Hugepage и Autogroup scheduler ) на 2.6.37-rc5-git3 - http://pavlinux.ru/hgpages/patch/transp_hugepage+sched_autogroup-2.6.37-rc5-g
RPM: для x86_64 (сделал make defconfig && make rpm) поэтому что там внутри не знаю :) http://pavlinux.ru/hgpages/rpm/kernel-2.6.37rc5+-1.x86_64.rpm
SRC-RPM: http://pavlinux.ru/hgpages/rpm/kernel-2.6.37rc5+-1.src.rpm
| | |
| |
| 3.10, б.б. (?), 04:50, 10/12/2010 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!!!
ну сейчас в убунту ядер нахреначат, одно простое, второе ХУЖЕ, третье ещё хуже, на каждый размер по ядру.
| | |
| 3.20, Аноним (-), 16:28, 10/12/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!!
погоняй так недельку, память дефрагментируется и привет форониксу.
| | |
| |
| 4.21, pavlinux (ok), 16:32, 10/12/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
>>Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!!
> погоняй так недельку, память дефрагментируется и привет форониксу.
или фрагментируется?
| | |
|
|
| 2.8, anonymous (??), 01:34, 10/12/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
по дефолту вроде с этим патчем надо madvise вызвать, не?
и будет работать с двумя видами страниц одновременно. Если треды, значит память будет шариться между потоками т.е. не важно в каких страница выделено, всё равно выделением на размерах меньше страницы занимаетются менеджеры памяти типа libhoard, им всё равно какими блоками OS выделяет, если запросил 2 раза по одному байту, выделение будет в одной страничке. Разница не очень будет видна (tlb cache при переключении между тредами не очищается). А вот если много процессов, тогда на переключении жирных apache2/php процессов (вполне могут жрать активно 128мб на процесс), вполне можно экономить на уменшении миссов в tlb cache при переключении между процессами.
| | |
| |
| 3.9, pavlinux (ok), 01:46, 10/12/2010 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> по дефолту вроде с этим патчем надо madvise вызвать, не?
Там два варианта:
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y - всегда
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set - или только при MADVISE
> (вполне могут жрать активно 128мб на процесс), вполне можно экономить на
> уменшении миссов в tlb cache при переключении между процессами.
Ну в общем да.
Минимальный размер оперативки для этого патча 4 Гига, рекомендуемый 32 :)
| | |
|
|
| 1.3, Sunder (ok), 00:07, 10/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 Это только для x86, потому что на x86-64 страницы давно уже не 4 кб :)
| | |
| |
| |
| |
| 4.25, user (??), 02:00, 11/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
 [root@ha1 yum.repos.d]# uname -m; getconf PAGESIZE
x86_64
4096
[root@ha1 yum.repos.d]#
| | |
|
|
|
| 1.11, ua9oas интересуется Миша Рыцаревъ (?), 06:36, 10/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
 А может ли этот патч модифицироваться в дальнейшем? Кроме того я не менее трех раз в день захожу на сайт kernel.org . Когда я зашел сегодня утром, то увидел, что во 1х стабильная версия поменялась с 2.6.36.1 на 2.6.36.2 и заодно там за эту ночь появились обновления веток тех, которые подолгу не обновлялись (2.6.27.57 , 2.6.32.57 . Заодно обе эти ветки почему то написаны там по 2 раза подряд каждая). Те изменения, что я там сейчас увидел это что, и есть этот патч или нет?
Кроме того в ядре при его обновлениях часто бывают случаи регрессий.
| | |
| 1.16, Аноним (-), 12:05, 10/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
1. Скорость возрастет даже для задач полностью умещающихся в память, если задача использует много памяти.
пример математика решение задач гидродинамики массивы 1 гиг. За счет уменьшения обращений к дескрипторам страничной памяти.
на pentium в свое время тесты показывали рост производительности порядка 5%
| | |
| |
| 2.17, Анон (?), 13:47, 10/12/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > 1. Скорость возрастет даже для задач полностью умещающихся в память, если задача
> использует много памяти.
> пример математика решение задач гидродинамики массивы 1 гиг. За счет уменьшения обращений
> к дескрипторам страничной памяти.
> на pentium в свое время тесты показывали рост производительности порядка 5%
Большой размер страниц нужен для СУБД. При больших размерах SGA накладные расходы при страничном доступе в среднем на порядок меньше для крупных страниц памяти.
| | |
|
| 1.18, konkor (?), 14:46, 10/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А что-нибудь среднее протестировать слабо?
Зачем такие крайности 4096 и 2097152?
Ну там 8к,16,32,64к...
| | |
| |
| 2.19, ff (??), 16:15, 10/12/2010 [^] [^^] [^^^] [ответить]
| +/– | |
железо не умеет.
x86 - 4 кб и 4мб
x86_64 - 4 кб и 2 мб
и у амд экспериментально есть страницы в несколько гб ;)
| | |
|
| 1.22, pavlinux (ok), 17:01, 10/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
http://sysbench.sourceforge.net
# ./sysbench --init-rng --num-threads=30000 --max-time=60 --test=threads run
FATAL: Thread #27578 creation failed, errno = 11 (Resource temporarily unavailable)
На ваниле, без этого патча
FATAL: Thread #32312 creation failed, errno = 11 (Resource temporarily unavailable)
Разница в 5000 тредов это уже не фигня. :)
----
P.S. 4 Gb RAM + 2Gb Swap
| | |
| 1.24, mrd_kaluga (?), 18:57, 10/12/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Для copy-on-write типа mod_perl поидее точно ахтунг. Правда на Линуксе оно в любом случае странно работает.
| | |
|
