The OpenNET Project / Index page

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

Оценка производительности Linux-ядра с оптимизирующим Hugepage-патчем

09.12.2010 23:29

Ресурс Phoronix представил результаты оценки эффективности работы "Transparent Hugepage" патча для Linux-ядра. Патч занимает более 7 тыс. строк и реализует технику увеличения базового размера адресуемых страниц памяти (без патча размер страницы составляет всегда 4096 байт, с патчем - 2 Мб ), что приводит к сокращению числа используемых TLB-блоков (Translation Lookaside Buffer) и расширению возможностей по задействованию выделенной, но неиспользуемой памяти, для кэширования системных данных (например, под дисковый кэш).

Теоретически реализуемый патчем подход должен привести к увеличению производительности самого ядра и активно использующих память приложений (например, патч эффективен при использовании систем виртуализации). Тем не менее, не исключены ситуации, когда патч оказывает негативное влияние. Например, приложение может выделить через функцию mmap большой блок памяти, но записать в него всего 1 байт данных. В этом случае, с патчем будет выделена страница памяти размером 2 Мб, а не 4 Кб как в ситуации без патча.

Из трех проведенных тестов, Hugepage-патч показал прирост производительности на 18% только в одном из вариантов теста NAS Parallel Benchmarks. Во втором варианте теста NAS Parallel Benchmarks и при выполнении операции изменения размера большого изображения в пакете GraphicsMagic, прирост производительности был практически не ощутим.

  1. Главная ссылка к новости (http://www.phoronix.com/scan.p...)
Лицензия: CC-BY
Тип: Обобщение
Короткая ссылка: https://opennet.ru/28950-linux
Ключевые слова: linux, kernel, mmap, memory, patch, speed, benchmark
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (26) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 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 +/
    > Слухайте, мож я обожрался Плацебо!!! Но по-моему ВСЁ ЛЕТАЕТ :) ВАУ!!!!

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

     
     
  • 4.12, Sunder_work (?), 10:11, 10/12/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Сколько надо столько и сделают. Вас не касается.
     
  • 4.23, Wormik (ok), 18:11, 10/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Причем здесь Убубен вообще?
     
  • 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 кб :)
     
     
  • 2.4, Аноним (-), 00:22, 10/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Эээ..?

    $ uname -m; getconf PAGESIZE
    x86_64
    4096

     
     
  • 3.5, Sunder (ok), 00:38, 10/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Проехали... моя ошибка.
     
     
  • 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]#
     
  • 2.6, z (??), 01:33, 10/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    На ia64 64k
     

  • 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.13, Аноним (-), 10:18, 10/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    <trollolo>О, в Линуск пришли superpages?</trollolo>
     
  • 1.14, Аноним (-), 10:22, 10/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А в BSD работа прозрачная и автоматическая.
    (высунул язык и размахивает им)

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

     
  • 1.15, Аноним (-), 11:58, 10/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А если сравнить пропатченное ядро с bsd системами, то что получиться?
     
  • 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 мб

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

     
     
  • 3.26, pavlinux (ok), 00:34, 15/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    2^30 - 1 гигабаб
    2^39 - 1/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 поидее точно ахтунг. Правда на Линуксе оно в любом случае странно работает.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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