Ресурс Phoronix представил (http://www.phoronix.com/scan.php?page=article&item=linux_tra...) результаты оценки эффективности работы "Transparent Hugepage (http://www.kernel.org/pub/linux/kernel/people/andrea/patches.../)" патча для Linux-ядра. Патч занимает более 7 тыс. строк и реализует (http://lwn.net/Articles/359158/) технику увеличения базового размера адресуемых страниц памяти (без патча размер страницы составляет всегда 4096 байт, с патчем - 2 Мб ), что приводит к сокращению числа используемых TLB-блоков (Translation Lookaside Buffer) и расширению возможностей по задействованию выделенной, но неиспользуемой памяти, для кэширования системных данных (например, под дисковый кэш).
Теоретически реализуемый патчем подход должен привести к увеличению производительности самого ядра и активно использующих память приложений. Тем не менее, не исключены ситуации, когда патч оказывает негативное влияние. Например, приложение может выделить через функцию mmap б...URL: http://www.phoronix.com/scan.php?page=article&item=linux_tra...
Новость: https://www.opennet.ru/opennews/art.shtml?num=28950
В общем, Фроникс даже не фкурил для чего это нужно...
Давай какой-то NAS бенчмарк гонять, сборку ГрафиксМэджик :)Это нужно для ВИРТУАЛОК!!! Для Многа Виртуалок!!! 500 - 1000 ...
А для приложений это ахтунг, точнее ахтунг для системы.
Вот представим сервак, например Апачь с 16000 тредов.
16000*2M ~= 31.25 Гиг, только для того чтоб запустить столько тредов.Прикиньте, даже маленький мямлик (memleak) на 4*PAGE_SIZE, хрясь и 8 мегов нету :)
---
Блин, ща прикручу этот и SCHED_AUTOGROUP патчу...
Устроим тотальный ДОС make -j 1024 :)
у них стандартный бенчмарк, на все случаи жизни :)
вот если бы патч оказывал негативное влияние на общую производительность системы в каком-либо из их тестов, то они бы конечно это в критику включили ) а специфических тестов от них редко удается дождаться, это же фороникс
> Блин, ща прикручу этот и SCHED_AUTOGROUP патчу...
> Устроим тотальный ДОС make -j 1024 :)Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!!!
---
% Чем меньше числа, тем лучше.
%
% Чистый malloc
%
# ./hgpages-benchmemset 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-benchmemset 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_autog...
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
> Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!!!ну сейчас в убунту ядер нахреначат, одно простое, второе ХУЖЕ, третье ещё хуже, на каждый размер по ядру.
Сколько надо столько и сделают. Вас не касается.
Причем здесь Убубен вообще?
>Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!!погоняй так недельку, память дефрагментируется и привет форониксу.
>>Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!!
> погоняй так недельку, память дефрагментируется и привет форониксу.или фрагментируется?
по дефолту вроде с этим патчем надо madvise вызвать, не?
и будет работать с двумя видами страниц одновременно. Если треды, значит память будет шариться между потоками т.е. не важно в каких страница выделено, всё равно выделением на размерах меньше страницы занимаетются менеджеры памяти типа libhoard, им всё равно какими блоками OS выделяет, если запросил 2 раза по одному байту, выделение будет в одной страничке. Разница не очень будет видна (tlb cache при переключении между тредами не очищается). А вот если много процессов, тогда на переключении жирных apache2/php процессов (вполне могут жрать активно 128мб на процесс), вполне можно экономить на уменшении миссов в tlb cache при переключении между процессами.
> по дефолту вроде с этим патчем надо madvise вызвать, не?Там два варианта:
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y - всегда
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set - или только при MADVISE
> (вполне могут жрать активно 128мб на процесс), вполне можно экономить на
> уменшении миссов в tlb cache при переключении между процессами.Ну в общем да.
Минимальный размер оперативки для этого патча 4 Гига, рекомендуемый 32 :)
Это только для x86, потому что на x86-64 страницы давно уже не 4 кб :)
Эээ..?$ uname -m; getconf PAGESIZE
x86_64
4096
Проехали... моя ошибка.
[root@ha1 yum.repos.d]# uname -m; getconf PAGESIZE
x86_64
4096
[root@ha1 yum.repos.d]#
На ia64 64k
А может ли этот патч модифицироваться в дальнейшем? Кроме того я не менее трех раз в день захожу на сайт kernel.org . Когда я зашел сегодня утром, то увидел, что во 1х стабильная версия поменялась с 2.6.36.1 на 2.6.36.2 и заодно там за эту ночь появились обновления веток тех, которые подолгу не обновлялись (2.6.27.57 , 2.6.32.57 . Заодно обе эти ветки почему то написаны там по 2 раза подряд каждая). Те изменения, что я там сейчас увидел это что, и есть этот патч или нет?
Кроме того в ядре при его обновлениях часто бывают случаи регрессий.
<trollolo>О, в Линуск пришли superpages?</trollolo>
А в BSD работа прозрачная и автоматическая.
(высунул язык и размахивает им)
А если сравнить пропатченное ядро с bsd системами, то что получиться?
1. Скорость возрастет даже для задач полностью умещающихся в память, если задача использует много памяти.пример математика решение задач гидродинамики массивы 1 гиг. За счет уменьшения обращений к дескрипторам страничной памяти.
на pentium в свое время тесты показывали рост производительности порядка 5%
> 1. Скорость возрастет даже для задач полностью умещающихся в память, если задача
> использует много памяти.
> пример математика решение задач гидродинамики массивы 1 гиг. За счет уменьшения обращений
> к дескрипторам страничной памяти.
> на pentium в свое время тесты показывали рост производительности порядка 5%Большой размер страниц нужен для СУБД. При больших размерах SGA накладные расходы при страничном доступе в среднем на порядок меньше для крупных страниц памяти.
А что-нибудь среднее протестировать слабо?
Зачем такие крайности 4096 и 2097152?
Ну там 8к,16,32,64к...
железо не умеет.x86 - 4 кб и 4мб
x86_64 - 4 кб и 2 мб
и у амд экспериментально есть страницы в несколько гб ;)
2^30 - 1 гигабаб
2^39 - 1/2 терабабы:)
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
Для copy-on-write типа mod_perl поидее точно ахтунг. Правда на Линуксе оно в любом случае странно работает.