The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Оценка производительности Linux-ядра с оптимизирующим Hugepa..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Оценка производительности 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...
Новость: http://www.opennet.me/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 email(??) 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 интересуется Миша Рыцаревъ email 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 работа прозрачная и автоматическая.
(высунул язык и размахивает им)

http://www.opennet.me/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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру