URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 73196
[ Назад ]

Исходное сообщение
"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."

Отправлено opennews , 09-Дек-10 23:39 
Ресурс 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...
Новость: http://www.opennet.me/opennews/art.shtml?num=28950


Содержание

Сообщения в этом обсуждении
"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено pavlinux , 09-Дек-10 23:39 
В общем, Фроникс даже не фкурил для чего это нужно...
Давай какой-то NAS бенчмарк гонять, сборку ГрафиксМэджик :)

Это нужно для ВИРТУАЛОК!!! Для Многа Виртуалок!!! 500 - 1000 ...

А для приложений это ахтунг, точнее ахтунг для системы.
Вот представим сервак, например Апачь с 16000 тредов.
16000*2M ~= 31.25 Гиг, только для того чтоб запустить столько тредов.

Прикиньте, даже маленький мямлик (memleak) на 4*PAGE_SIZE, хрясь и 8 мегов нету :)

---

Блин, ща прикручу этот и SCHED_AUTOGROUP патчу...

Устроим тотальный ДОС make -j 1024 :)


"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено Sylvia , 09-Дек-10 23:55 
у них стандартный бенчмарк, на все случаи жизни :)
вот если бы патч оказывал негативное влияние на общую производительность системы в каком-либо из их тестов, то они бы конечно это в критику включили ) а специфических тестов от них редко удается дождаться, это же фороникс

"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено pavlinux , 10-Дек-10 01:34 
> Блин, ща прикручу этот и 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_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


"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено б.б. , 10-Дек-10 04:50 
> Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!!!

ну сейчас в убунту ядер нахреначат, одно простое, второе ХУЖЕ, третье ещё хуже, на каждый размер по ядру.


"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено Sunder_work , 10-Дек-10 10:11 
Сколько надо столько и сделают. Вас не касается.

"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено Wormik , 10-Дек-10 18:11 
Причем здесь Убубен вообще?

"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено Аноним , 10-Дек-10 16:28 
>Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!!

погоняй так недельку, память дефрагментируется и привет форониксу.


"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено pavlinux , 10-Дек-10 16:32 
>>Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!!
> погоняй так недельку, память дефрагментируется и привет форониксу.

или фрагментируется?


"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено anonymous , 10-Дек-10 01:34 
по дефолту вроде с этим патчем надо madvise вызвать, не?
и будет работать с двумя видами страниц одновременно. Если треды, значит память будет шариться между потоками т.е. не важно в каких страница выделено, всё равно выделением на размерах меньше страницы занимаетются менеджеры памяти типа libhoard, им всё равно какими блоками OS выделяет, если запросил 2 раза по одному байту, выделение будет в одной страничке. Разница не очень будет видна (tlb cache при переключении между тредами не очищается). А вот если много процессов, тогда на переключении жирных apache2/php процессов (вполне могут жрать активно 128мб на процесс), вполне можно экономить на уменшении миссов в tlb cache при переключении между процессами.

"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено pavlinux , 10-Дек-10 01:46 
> по дефолту вроде с этим патчем надо madvise вызвать, не?

Там два варианта:

CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y - всегда
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set - или только при MADVISE


> (вполне могут жрать активно 128мб на процесс), вполне можно экономить на
> уменшении миссов в tlb cache при переключении между процессами.

Ну в общем да.

Минимальный размер оперативки для этого патча 4 Гига, рекомендуемый 32 :)


"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено Sunder , 10-Дек-10 00:07 
Это только для x86, потому что на x86-64 страницы давно уже не 4 кб :)

"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено Аноним , 10-Дек-10 00:22 
Эээ..?

$ uname -m; getconf PAGESIZE
x86_64
4096


"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено Sunder , 10-Дек-10 00:38 
Проехали... моя ошибка.

"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено user , 11-Дек-10 02:00 
[root@ha1 yum.repos.d]# uname -m; getconf PAGESIZE
x86_64
4096
[root@ha1 yum.repos.d]#

"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено z , 10-Дек-10 01:33 
На ia64 64k

"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено ua9oas интересуется Миша Рыцаревъ , 10-Дек-10 06:36 
  А может ли этот патч модифицироваться в дальнейшем? Кроме того я не менее трех раз в день захожу на сайт kernel.org . Когда я зашел сегодня утром, то увидел, что во 1х стабильная версия поменялась с 2.6.36.1 на 2.6.36.2 и заодно там за эту ночь появились обновления веток тех, которые подолгу не обновлялись (2.6.27.57 , 2.6.32.57 . Заодно обе эти ветки почему то написаны там по 2 раза подряд каждая). Те изменения, что я там сейчас увидел это что, и есть этот патч или нет?
  Кроме того в ядре при его обновлениях часто бывают случаи регрессий.

"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено Аноним , 10-Дек-10 10:18 
<trollolo>О, в Линуск пришли superpages?</trollolo>

"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено Аноним , 10-Дек-10 10:22 
А в BSD работа прозрачная и автоматическая.
(высунул язык и размахивает им)

http://www.opennet.me/opennews/art.shtml?num=21576


"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено Аноним , 10-Дек-10 11:58 
А если сравнить пропатченное ядро с bsd системами, то что получиться?

"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено Аноним , 10-Дек-10 12:05 
1. Скорость возрастет даже для задач полностью умещающихся в память, если задача использует много памяти.

пример математика решение задач гидродинамики массивы 1 гиг. За счет уменьшения обращений к дескрипторам страничной памяти.

на pentium в свое время тесты показывали рост производительности порядка 5%


"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено Анон , 10-Дек-10 13:47 
> 1. Скорость возрастет даже для задач полностью умещающихся в память, если задача
> использует много памяти.
> пример математика решение задач гидродинамики массивы 1 гиг. За счет уменьшения обращений
> к дескрипторам страничной памяти.
> на pentium в свое время тесты показывали рост производительности порядка 5%

Большой размер страниц нужен для СУБД. При больших размерах SGA накладные расходы при страничном доступе в среднем на порядок меньше для крупных страниц памяти.


"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено konkor , 10-Дек-10 14:46 
А что-нибудь среднее протестировать слабо?
Зачем такие крайности 4096 и 2097152?
Ну  там 8к,16,32,64к...

"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено ff , 10-Дек-10 16:15 
железо не умеет.

x86 - 4 кб и 4мб

x86_64 - 4 кб и 2 мб

и у амд экспериментально есть страницы в несколько гб ;)


"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено pavlinux , 15-Дек-10 00:34 
2^30 - 1 гигабаб
2^39 - 1/2 терабабы

:)


"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено pavlinux , 10-Дек-10 17:01 
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


"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Отправлено mrd_kaluga , 10-Дек-10 18:57 
Для copy-on-write типа mod_perl поидее точно ахтунг. Правда на Линуксе оно в любом случае странно работает.