The OpenNET Project / Index page

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

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

Ресурс 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
Тип: Обобщение
Ключевые слова: linux, kernel, mmap, memory, patch, speed, benchmark
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Линейный вид | Ajax | Показать все | RSS
 
  • 1.1, pavlinux, 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, 23:55, 09/12/2010 [^] [ответить] [смотреть все] [показать ветку]
  • +1 +/
    у них стандартный бенчмарк, на все случаи жизни вот если бы патч оказывал нег... весь текст скрыт [показать] [показать ветку]
     
  • 2.7, pavlinux, 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, 18:11, 10/12/2010 [^] [ответить] [смотреть все]  
  • +/
    Причем здесь Убубен вообще?
     
  • 3.20, Аноним, 16:28, 10/12/2010 [^] [ответить] [смотреть все]  
  • –1 +/
    погоняй так недельку, память дефрагментируется и привет форониксу ... весь текст скрыт [показать]
     
     
  • 4.21, pavlinux, 16:32, 10/12/2010 [^] [ответить] [смотреть все]  
  • +2 +/
    или фрагментируется ... весь текст скрыт [показать]
     
  • 2.8, anonymous, 01:34, 10/12/2010 [^] [ответить] [смотреть все] [показать ветку]  
  • +1 +/
    по дефолту вроде с этим патчем надо madvise вызвать, не и будет работать с двум... весь текст скрыт [показать] [показать ветку]
     
     
  • 3.9, pavlinux, 01:46, 10/12/2010 [^] [ответить] [смотреть все]  
  • +2 +/
    Там два варианта CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS y - всегда CONFIG_TRANSPA... весь текст скрыт [показать]
     
  • 1.3, Sunder, 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, 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 rep... весь текст скрыт [показать]
     
  • 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... весь текст скрыт [показать]
     
  • 1.15, Аноним, 11:58, 10/12/2010 [ответить] [смотреть все]  
  • +/
    А если сравнить пропатченное ядро с bsd системами, то что получиться?
     
  • 1.16, Аноним, 12:05, 10/12/2010 [ответить] [смотреть все]  
  • +/
    1 Скорость возрастет даже для задач полностью умещающихся в память, если задача... весь текст скрыт [показать]
     
     
  • 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, 00:34, 15/12/2010 [^] [ответить] [смотреть все]  
  • +/
    2^30 - 1 гигабаб
    2^39 - 1/2 терабабы

    :)

     
  • 1.22, pavlinux, 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:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor