LINUX.ORG.RU

BFQ не очень хорош для многих SSD

 , , ,


2

2

Public Service Announcement:

Случайно обнаружил, что bfq на многих ssd сводит производительность к однопоточной.
На nvme и sata Samsung’ах всё в порядке, и пропускная способность bfq растёт с количеством одновременных запросов.
А на ADATA и Transcend вот так:

    Device Model:     TS256GMTS400S
    Serial Number:    0F109200E32506200140
    Firmware Version: P1225CH4
    ATA Version is:   ACS-2 (minor revision not indicated)
    SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
    Timing O_DIRECT disk reads: 1472 MB in  3.00 seconds = 489.96 MB/sec

    /dev/sda, 256.06 GB, 1 threads:
     512   B blocks: 11361.3 IO/s,   5.5 MiB/s ( 46.5 Mbit/s)
       1 KiB blocks: 7762.1 IO/s,   7.6 MiB/s ( 63.6 Mbit/s)
       2 KiB blocks: 4545.7 IO/s,   8.9 MiB/s ( 74.5 Mbit/s)
       4 KiB blocks: 2476.4 IO/s,   9.7 MiB/s ( 81.1 Mbit/s)
       8 KiB blocks: 2483.9 IO/s,  19.4 MiB/s (162.8 Mbit/s)
      16 KiB blocks: 2271.1 IO/s,  35.5 MiB/s (297.7 Mbit/s)
      32 KiB blocks: 1941.6 IO/s,  60.7 MiB/s (509.0 Mbit/s)
      64 KiB blocks: 1360.1 IO/s,  85.0 MiB/s (713.1 Mbit/s)
     128 KiB blocks:  968.5 IO/s, 121.1 MiB/s (  1.0 Gbit/s)

    /dev/sda, 256.06 GB, 4 threads:
     512   B blocks: 12958.1 IO/s,   6.3 MiB/s ( 53.1 Mbit/s)
       1 KiB blocks: 8832.4 IO/s,   8.6 MiB/s ( 72.4 Mbit/s)
       2 KiB blocks: 4945.6 IO/s,   9.7 MiB/s ( 81.0 Mbit/s)
       4 KiB blocks: 2598.6 IO/s,  10.2 MiB/s ( 85.2 Mbit/s)
       8 KiB blocks: 2553.3 IO/s,  19.9 MiB/s (167.3 Mbit/s)
      16 KiB blocks: 2410.9 IO/s,  37.7 MiB/s (316.0 Mbit/s)
      32 KiB blocks: 2089.0 IO/s,  65.3 MiB/s (547.6 Mbit/s)
      64 KiB blocks: 1463.4 IO/s,  91.5 MiB/s (767.2 Mbit/s)
     128 KiB blocks: 1056.8 IO/s, 132.1 MiB/s (  1.1 Gbit/s)

Этот же Transcend, но с mq-deadline:

/dev/sda, 256.06 GB, 4 threads:
 512   B blocks: 42803.6 IO/s,  20.9 MiB/s (175.3 Mbit/s)
   1 KiB blocks: 34526.3 IO/s,  33.7 MiB/s (282.8 Mbit/s)
   2 KiB blocks: 24795.4 IO/s,  48.4 MiB/s (406.2 Mbit/s)
   4 KiB blocks: 15848.5 IO/s,  61.9 MiB/s (519.3 Mbit/s)
   8 KiB blocks: 15403.9 IO/s, 120.3 MiB/s (  1.0 Gbit/s)
  16 KiB blocks: 9705.9 IO/s, 151.7 MiB/s (  1.3 Gbit/s)
  32 KiB blocks: 5583.4 IO/s, 174.5 MiB/s (  1.5 Gbit/s)
  64 KiB blocks: 2967.9 IO/s, 185.5 MiB/s (  1.6 Gbit/s)
 128 KiB blocks: 1666.6 IO/s, 208.3 MiB/s (  1.7 Gbit/s)

Если у вас не Самсунг, то bfq лучше не использовать.

P.S. Ещё едет терабайтный WD Blue, дополню позже.
P.P.S. Linux lin 5.10.0-0.bpo.5-amd64 #1 SMP Debian 5.10.24-1~bpo10+1 (2021-03-29) x86_64 GNU/Linux

★★★★★

Ответ на: комментарий от token_polyak

Совсем без планировщика слегка стрёмно: конечному юзеру десктопа важны задержки, жертвовать throughput в пользу latency можно и нужно.
Но с bfq что-то пошло совсем не так. Скорее всего его пилят на самсах, а на всём остальном он убивает производительность до уровня однопотока.

Посмотрим ещё, что WD Blue скажет.

aidaho ★★★★★ ()

На nvme и sata Samsung’ах всё в порядке, и пропускная способность bfq растёт с количеством одновременных запросов.

А на ADATA и Transcend вот так:

В чем же разница устройств, из-за которой планировщик даёт разный результат?

wandrien ()
Ответ на: комментарий от Minona

А если внутренний планировщик ssd решит, что для красивых циферок пропускной способности лучше отложить 512 байтовый запрос на глиф для emacs на потом, а прям щас удовлетворить вооон те линейные на 1Mb+?

Я не доверяю накопителю шифрование и управление очередями.

aidaho ★★★★★ ()
Ответ на: комментарий от aidaho

А если внутренний планировщик ssd решит

а с чего ты взял что там что-то сложнее обычной FIFO-очереди, если она там вообще есть?
если бы в дисках были вумные планировщики нафига бы стали изобретать ядерные?
---
а с none тестировал?

Minona ★★ ()
Последнее исправление: Minona (всего исправлений: 1)
Ответ на: комментарий от anonymous

Разве я тебя не предупреждал, что mq-deadline лучше?

Вроде нет.

Я когда-то наткнулся на бенчмарк, так с того времени и ставлю бфкъю.

Посмотрел актуальный — да, вы правы. Хотя на нвме буду пробовать без планировщика ввода-вывода.

fernandos ★★ ()
Ответ на: комментарий от anonymous

wear leveling не влияет на чтение, а при записи делает тоже самое что и CoW в ZFS.
в ssd, в отличии от hdd, время выполнения операций не зависит от их порядка.
так что сложнее обычной FIFO очереди смысла городить нет.
я так же думаю что чуваки писавшие фирмварь лучше знают как их девайс должен выполнять запросы =)

Minona ★★ ()
Ответ на: комментарий от deterok

Свежераспакованный WDC WDBNCE0010PNC:

root@lin:/home/aidaho# echo 3 > /proc/sys/vm/drop_caches && iops -n 1 /dev/sda
/dev/sda,   1.00 TB, 1 threads:
 512   B blocks: 25510.1 IO/s,  12.5 MiB/s (104.5 Mbit/s)
   1 KiB blocks: 20710.5 IO/s,  20.2 MiB/s (169.7 Mbit/s)
   2 KiB blocks: 15377.4 IO/s,  30.0 MiB/s (251.9 Mbit/s)
   4 KiB blocks: 10167.7 IO/s,  39.7 MiB/s (333.2 Mbit/s)
   8 KiB blocks: 9319.9 IO/s,  72.8 MiB/s (610.8 Mbit/s)
  16 KiB blocks: 6957.0 IO/s, 108.7 MiB/s (911.9 Mbit/s)
  32 KiB blocks: 4552.4 IO/s, 142.3 MiB/s (  1.2 Gbit/s)
  64 KiB blocks: 2730.9 IO/s, 170.7 MiB/s (  1.4 Gbit/s)
 128 KiB blocks: 1513.1 IO/s, 189.1 MiB/s (  1.6 Gbit/s)
^Ccaught ctrl-c, bye.
root@lin:/home/aidaho# echo 3 > /proc/sys/vm/drop_caches && iops -n 4 /dev/sda
/dev/sda,   1.00 TB, 4 threads:
 512   B blocks: 27283.6 IO/s,  13.3 MiB/s (111.8 Mbit/s)
   1 KiB blocks: 22499.4 IO/s,  22.0 MiB/s (184.3 Mbit/s)
   2 KiB blocks: 16124.1 IO/s,  31.5 MiB/s (264.2 Mbit/s)
   4 KiB blocks: 10609.2 IO/s,  41.4 MiB/s (347.6 Mbit/s)
   8 KiB blocks: 10220.9 IO/s,  79.9 MiB/s (669.8 Mbit/s)
  16 KiB blocks: 7599.9 IO/s, 118.7 MiB/s (996.1 Mbit/s)
  32 KiB blocks: 5056.3 IO/s, 158.0 MiB/s (  1.3 Gbit/s)
  64 KiB blocks: 2889.6 IO/s, 180.6 MiB/s (  1.5 Gbit/s)
 128 KiB blocks: 1725.2 IO/s, 215.7 MiB/s (  1.8 Gbit/s)
^Ccaught ctrl-c, bye.
root@lin:/home/aidaho# echo mq-deadline > /sys/block/sda/queue/scheduler
root@lin:/home/aidaho# echo 3 > /proc/sys/vm/drop_caches && iops -n 4 /dev/sda
/dev/sda,   1.00 TB, 4 threads:
 512   B blocks: 71864.0 IO/s,  35.1 MiB/s (294.4 Mbit/s)
   1 KiB blocks: 59488.7 IO/s,  58.1 MiB/s (487.3 Mbit/s)
   2 KiB blocks: 39106.0 IO/s,  76.4 MiB/s (640.7 Mbit/s)
   4 KiB blocks: 23178.4 IO/s,  90.5 MiB/s (759.5 Mbit/s)
   8 KiB blocks: 22566.7 IO/s, 176.3 MiB/s (  1.5 Gbit/s)
  16 KiB blocks: 13688.6 IO/s, 213.9 MiB/s (  1.8 Gbit/s)
  32 KiB blocks: 7642.7 IO/s, 238.8 MiB/s (  2.0 Gbit/s)
  64 KiB blocks: 4007.4 IO/s, 250.5 MiB/s (  2.1 Gbit/s)
 128 KiB blocks: 2194.4 IO/s, 274.3 MiB/s (  2.3 Gbit/s)

В общем, bfq можно закапывать.
Fair queue ценой сокращения очереди до единицы не имеет никакого смысла на ssd.

aidaho ★★★★★ ()
Ответ на: комментарий от Minona

а с чего ты взял что там что-то сложнее обычной FIFO-очереди, если она там вообще есть?

Я не знаю что там в каждом конкретном ssd наколдовано, и что главнее — не хочу знать.
Меня интересует одинаковое поведение на каждой системе, а конкретно: плавность/отзывчивость десктопа под нагрузкой.

а с none тестировал?

С none примерно на 1.5-2% выше пропускная способность.

Расчехлил fio, чтобы посмотреть на задержки (SATA WD Blue 1Tb):

none:

read: IOPS=30.9k, BW=121MiB/s (126MB/s)(2413MiB/20001msec)
    clat (usec): min=24, max=5525, avg=31.23, stdev=12.30

mq-deadline:

read: IOPS=30.2k, BW=118MiB/s (124MB/s)(2356MiB/20001msec)
    clat (usec): min=24, max=4846, avg=31.94, stdev= 9.55

Т.е. для интерактивной машины mq-deadline незначительно лучше чем встроенный планировщик (с данным конкретным ssd).

aidaho ★★★★★ ()
Ответ на: комментарий от Minona

если быть точным, то у none немного выше иопсы и ниже латенси

Не так. У none выше отклонение от среднего и худший worst case.

В худшем случае с none глиф емакса задержится на 5525μs, а с mq-deadline, на 4846μs.
Разница небольшая, но с точки зрения десктопа она в пользу mq-deadline.

aidaho ★★★★★ ()
Ответ на: комментарий от aidaho

нет, твой глиф емакса в большинстве запросов будет проявляться одинаково быстро и лишь в 1 запросе из дохрена проявится на 1мс позже, ты этого даже не заметишь.
с точки зрения погрешности измерений разницы между ними вообще нет.

Minona ★★ ()

Года 3 назад (когда менял железо) заморачивался чтением интернетов и тестами…. Итого на всех nvme как везде и советуют с тех пор none.

anonymous ()
Ответ на: комментарий от aidaho

Недоверять можно сколько угодно, но технически только у прошивки ссд есть информация о конфигурации чипов флэш памяти в конкретном накопителе, открытых в данный момент страницах, и содержимом кэша(если он есть). Линуксовый планировщик не имеет этой информации и в принципе не может чего либо оптимизировать. BFQ был придуман для шпиндельных устройств хранения и поэтому пытается переупорядочить запросы для минимизации перепозиционирования головок. Для ssd в этом нет смысла, только повышенный расход памяти и повышение латентности доступа

cobold ★★★ ()
Ответ на: комментарий от cobold

Ок, вы все правы.
Оставшийся со вчерашних тестов в none nvme высрал под (реальной, не тестовой) нагрузкой вот это:

[85513.509380] irq 123: nobody cared (try booting with the "irqpoll" option)
[85513.509384] CPU: 2 PID: 28218 Comm: pylint Tainted: G     U            5.10.0-0.bpo.7-amd64 #1 Debian 5.10.40-1~bpo10+1
[85513.509385] Hardware name: Dell Inc. OptiPlex 5050/0782GW, BIOS 1.14.0 07/02/2020
[85513.509385] Call Trace:
[85513.509387]  <IRQ>
[85513.509392]  dump_stack+0x6d/0x88
[85513.509395]  __report_bad_irq+0x37/0xae
[85513.509397]  note_interrupt.cold.11+0xa/0x60
[85513.509399]  handle_irq_event_percpu+0x6a/0x80
[85513.509400]  handle_irq_event+0x36/0x60                                                                                                                                                                                                                     [85513.509402]  handle_edge_irq+0x82/0x190
[85513.509404]  asm_call_irq_on_stack+0xf/0x20
[85513.509405]  </IRQ>
[85513.509407]  common_interrupt+0xb9/0x130
[85513.509409]  asm_common_interrupt+0x1e/0x40
[85513.509412] RIP: 0010:scan_swap_map_slots+0x42c/0x690
[85513.509413] Code: 0d d1 36 cd 01 48 8b 44 24 10 41 8b 56 64 48 83 c0 01 48 89 44 24 10 48 39 d0 0f 87 01 01 00 00 49 8b 76 40 48 01 c6 80 3e 00 <0f> 84 a6 00 00 00 48 8b 15 a7 36 cd 01 48 01 d2 48 39 ca 7d 0c 0f
[85513.509414] RSP: 0000:ffffb244a325f7f8 EFLAGS: 00000202
[85513.509416] RAX: 0000000000357d88 RBX: 00000000000000b5 RCX: 0000000000d12560
[85513.509416] RDX: 00000000003e7e6e RSI: ffffb2448335cd88 RDI: ffff978bbdd2bc00
[85513.509417] RBP: 0000000000000000 R08: 0000000000025d91 R09: 0000000001b4cd65
[85513.509418] R10: 0000000001b4cd65 R11: 0000000000000033 R12: ffff97851289baf0
[85513.509419] R13: 0000000000000001 R14: ffff97851289ba00 R15: ffff9784c3407400
[85513.509421]  ? scan_swap_map_slots+0x457/0x690
[85513.509423]  get_swap_pages+0x20f/0x370
[85513.509424]  get_swap_page+0xc9/0x1f0
[85513.509426]  add_to_swap+0x14/0x70
[85513.509428]  shrink_page_list+0x8b3/0xd10
[85513.509430]  shrink_inactive_list+0x193/0x3d0
[85513.509431]  shrink_lruvec+0x40e/0x660
[85513.509433]  shrink_node+0x233/0x6d0
[85513.509435]  do_try_to_free_pages+0xc6/0x3d0
[85513.509437]  ? sched_clock_cpu+0xc/0xb0
[85513.509438]  try_to_free_mem_cgroup_pages+0xeb/0x1c0
[85513.509441]  try_charge+0x29b/0x6f0
[85513.509442]  ? __alloc_pages_nodemask+0x15b/0x300
[85513.509444]  mem_cgroup_charge+0x80/0x250
[85513.509446]  wp_page_copy+0x10b/0x790
[85513.509448]  ? __swap_entry_free+0x4f/0x90
[85513.509449]  ? do_swap_page+0x412/0x810
[85513.509451]  handle_mm_fault+0x604/0x1640
[85513.509453]  exc_page_fault+0x296/0x530
[85513.509454]  ? asm_exc_page_fault+0x8/0x30
[85513.509455]  asm_exc_page_fault+0x1e/0x30
[85513.509457] RIP: 0033:0x51da1e
[85513.509458] Code: f6 80 a9 00 00 00 40 75 03 31 c0 c3 53 48 8b 80 48 01 00 00 48 89 fb 48 85 c0 75 20 48 8b 53 f8 48 83 fa 01 7e 08 48 83 ea 02 <48> 89 53 f8 31 c0 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 3d f0 28
[85513.509459] RSP: 002b:00007ffc28d36b60 EFLAGS: 00010246
[85513.509460] RAX: 0000000000000000 RBX: 00007f458d030d08 RCX: 0000000000000003
[85513.509461] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007f458d030d08
[85513.509461] RBP: 000000000051d9f0 R08: 00007f458d032ab0 R09: 00007f458d032ab0
[85513.509462] R10: 0000000000000000 R11: 00007f458d032ab0 R12: 0000000000000000
[85513.509463] R13: 00007f458d031c60 R14: 000000000000000f R15: 0000000000000d42
[85513.509464] handlers:
[85513.509468] [<00000000c85d232f>] nvme_irq [nvme]
[85513.509469] Disabling IRQ #123

Оправдывайтесь.

aidaho ★★★★★ ()
Ответ на: комментарий от aidaho

логика из разряда — я встал с левой ноги и на меня накакала птичка; вывод — надо вставать с правой.

планировщик никакого отношения к прерываниям не имеет.
косяк где-то в HW/FW/Driver.
вот, почитай: https://stackoverflow.com/questions/13861282/understanding-kernel-message-nob...

Minona ★★ ()
Ответ на: комментарий от Minona

В современных SSD алгоритмы намного сложнее «обычной FIFO-очереди» - хотя бы потому, что там есть кэш а запись последовательная в специально подготовленные блоки.

Nastishka ★★★★★ ()
Ответ на: комментарий от aidaho

Похоже, уровень веры в по накопителя в этом треде достиг религиозного.

то что ты не хочешь принять факт что приведённый тобой трейс никак не связан с выбранным планировщиком не влияет на окружающую действительность

anonymous ()
Ответ на: комментарий от aidaho

ну давай сначала:

BFQ не очень хорош для многих SSD

для SSD любой планировщик в/в избыточен, поэтому — none.

Оставшийся со вчерашних тестов в none nvme высрал под (реальной, не тестовой) нагрузкой вот это:

этот трейс не имеет отношения к планировщику никакого.

Похоже, уровень веры в по накопителя в этом треде достиг религиозного.

а вера в планировщики ядра?

Minona ★★ ()
Ответ на: комментарий от Minona

избыточен

Необязателен.

этот трейс не имеет отношения к планировщику никакого

Верно. Планировщик был отключён.

а вера в планировщики ядра?

Несколько фактов:

  1. единственный персонаж в треде с бенчмарками и пруфами чего-либо, это я
  2. тред создан, мною чтобы облить помоями планировщик ядра
  3. я зачем-то спорю с людьми, которые считают код в любом ssd наилучшим для любых задач

Пожалуй, на этом закончу.

aidaho ★★★★★ ()
Ответ на: комментарий от aidaho

Необязателен

избыточен

единственный персонаж в треде с бенчмарками и пруфами чего-либо, это я

твои бенчмарки и пруфы только подтверждают избыточность и бесполезность планировщика для ssd

тред создан, мною чтобы облить помоями планировщик ядра

т.е. ты доказал очевидный факт что планировщик для ssd не нужен, но при этом недоволен этим фактом

я зачем-то спорю с людьми, которые считают код в любом ssd наилучшим для любых задач

где это утверждалось?
в треде говорилось что фирмварь ssd лучше планировщика знает как ей выполнять запросы в/в в этом ssd

Пожалуй, на этом закончу.

ну да, зачем оспаривать очевидное.

Minona ★★ ()
Ответ на: комментарий от SkyMaverick

Я тоже их видел. Фороникс какими-либо выводами из тестов не изобилует, а мне сейчас интересен именно, что называется, abstract — зачем Kyber был придуман, как работает (крупными мазками), какие задачи призван решать и насколько хорошо у него это получается.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от aidaho

В худшем случае с none глиф емакса задержится на 5525μs, а с mq-deadline, на 4846μs. Разница небольшая, но с точки зрения десктопа она в пользу mq-deadline.

Это чем? А то, паанимаешь, бенчи говорят, что не надо никаких планировщиков. А раз так - дело за малым. Вырубил в ядре и всё заверте…

А Ваши «ой баюсь-баюсь я none на рабочей лошади» - это ты деткам рассказывай.

shleemypants ()