форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+/–
Сообщение от opennews (ok) on 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... Новость: https://www.opennet.ru/opennews/art.shtml?num=28950
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+4 +/–
Сообщение от pavlinux (ok) on 09-Дек-10, 23:39
В общем, Фроникс даже не фкурил для чего это нужно... Давай какой-то NAS бенчмарк гонять, сборку ГрафиксМэджик :) Это нужно для ВИРТУАЛОК!!! Для Многа Виртуалок!!! 500 - 1000 ... А для приложений это ахтунг, точнее ахтунг для системы. Вот представим сервак, например Апачь с 16000 тредов. 16000*2M ~= 31.25 Гиг, только для того чтоб запустить столько тредов. Прикиньте, даже маленький мямлик (memleak) на 4*PAGE_SIZE, хрясь и 8 мегов нету :) --- Блин, ща прикручу этот и SCHED_AUTOGROUP патчу... Устроим тотальный ДОС make -j 1024 :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+1 +/–
	Сообщение от Sylvia (ok) on 09-Дек-10, 23:55
	у них стандартный бенчмарк, на все случаи жизни :) вот если бы патч оказывал негативное влияние на общую производительность системы в каком-либо из их тестов, то они бы конечно это в критику включили ) а специфических тестов от них редко удается дождаться, это же фороникс
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	7. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+6 +/–
	Сообщение от pavlinux (ok) on 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
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	10. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	–2 +/–
	Сообщение от б.б. on 10-Дек-10, 04:50
	> Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!!! ну сейчас в убунту ядер нахреначат, одно простое, второе ХУЖЕ, третье ещё хуже, на каждый размер по ядру.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	12. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	–2 +/–
	Сообщение от Sunder_work on 10-Дек-10, 10:11
	Сколько надо столько и сделают. Вас не касается.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	23. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+/–
	Сообщение от Wormik (ok) on 10-Дек-10, 18:11
	Причем здесь Убубен вообще?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	20. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	–1 +/–
	Сообщение от Аноним (??) on 10-Дек-10, 16:28
	>Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!! погоняй так недельку, память дефрагментируется и привет форониксу.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	21. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+2 +/–
	Сообщение от pavlinux (ok) on 10-Дек-10, 16:32
	>>Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!! > погоняй так недельку, память дефрагментируется и привет форониксу. или фрагментируется?
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

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

	9. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+2 +/–
	Сообщение от pavlinux (ok) on 10-Дек-10, 01:46
	> по дефолту вроде с этим патчем надо madvise вызвать, не? Там два варианта: CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y - всегда # CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set - или только при MADVISE > (вполне могут жрать активно 128мб на процесс), вполне можно экономить на > уменшении миссов в tlb cache при переключении между процессами. Ну в общем да. Минимальный размер оперативки для этого патча 4 Гига, рекомендуемый 32 :)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

3. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	–2 +/–
Сообщение от Sunder (ok) on 10-Дек-10, 00:07
Это только для x86, потому что на x86-64 страницы давно уже не 4 кб :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+1 +/–
	Сообщение от Аноним (??) on 10-Дек-10, 00:22
	Эээ..? $ uname -m; getconf PAGESIZE x86_64 4096
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+/–
	Сообщение от Sunder (ok) on 10-Дек-10, 00:38
	Проехали... моя ошибка.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	25. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+/–
	Сообщение от user (??) on 11-Дек-10, 02:00
	[root@ha1 yum.repos.d]# uname -m; getconf PAGESIZE x86_64 4096 [root@ha1 yum.repos.d]#
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	6. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+/–
	Сообщение от z (??) on 10-Дек-10, 01:33
	На ia64 64k
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

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

13. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+1 +/–
Сообщение от Аноним (??) on 10-Дек-10, 10:18
<trollolo>О, в Линуск пришли superpages?</trollolo>
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

14. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+/–
Сообщение от Аноним (??) on 10-Дек-10, 10:22
А в BSD работа прозрачная и автоматическая. (высунул язык и размахивает им) https://www.opennet.ru/opennews/art.shtml?num=21576
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+/–
Сообщение от Аноним (??) on 10-Дек-10, 11:58
А если сравнить пропатченное ядро с bsd системами, то что получиться?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+/–
Сообщение от Аноним (??) on 10-Дек-10, 12:05
1. Скорость возрастет даже для задач полностью умещающихся в память, если задача использует много памяти. пример математика решение задач гидродинамики массивы 1 гиг. За счет уменьшения обращений к дескрипторам страничной памяти. на pentium в свое время тесты показывали рост производительности порядка 5%
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	17. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+/–
	Сообщение от Анон on 10-Дек-10, 13:47
	> 1. Скорость возрастет даже для задач полностью умещающихся в память, если задача > использует много памяти. > пример математика решение задач гидродинамики массивы 1 гиг. За счет уменьшения обращений > к дескрипторам страничной памяти. > на pentium в свое время тесты показывали рост производительности порядка 5% Большой размер страниц нужен для СУБД. При больших размерах SGA накладные расходы при страничном доступе в среднем на порядок меньше для крупных страниц памяти.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+/–
Сообщение от konkor on 10-Дек-10, 14:46
А что-нибудь среднее протестировать слабо? Зачем такие крайности 4096 и 2097152? Ну  там 8к,16,32,64к...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+/–
	Сообщение от ff (??) on 10-Дек-10, 16:15
	железо не умеет. x86 - 4 кб и 4мб x86_64 - 4 кб и 2 мб и у амд экспериментально есть страницы в несколько гб ;)
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	26. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+/–
	Сообщение от pavlinux (ok) on 15-Дек-10, 00:34
	2^30 - 1 гигабаб 2^39 - 1/2 терабабы :)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

22. "Оценка производительности Linux-ядра с оптимизирующим Hugepa..."	+/–
Сообщение от pavlinux (ok) on 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
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема