История изменений
Исправление bugfixer, (текущая версия) :
Есть у кого-нибудь теоритические познания - которые могут объяснить в чём может быть дело?
Даже не знаю с чего и начать. Неправильно всё, начиная с постановки вопроса и заканчивая методикой измерений.
Если изначально IO-bound workload неожиданно становится CPU-bound (а уж тем более congested on a single mutex) - Вы что-то делаете фундаментально неправильно.
Если задача добиться максимума TPS - надо стараться держать все CQ Ваших SSD busy. И это выходит очень далеко за рамки дискуссии о mutex’ах.
Настоящая параллельная запись (с точки зрения прогаммы, а не диска конечно) вернется в программу тогда когда в наборе активных файлов останется 30
Управление в апликуху вернётся в момент когда ядро получит данные, а не когда они упадут на диск. Flushes - отдельная история.
Конечно в реальной работе этого кода никогда не будет в принципе более 3 потоков
Почему мы тогда вообще это обсуждаем?
Но вот просто очень интересно во первых почему возникает такая разница
Алгоритм крив донельзя.
Отпускает мьютекс, от котрый один на всех
Жесть.
спит 10 миллисекнуд
Double жесть.
сколько открыто файлов и список, с левого конца которого будет файл в который дольше всего не писали
Грамотный IO-scheduling - это искусство. Повторюсь - я уверен Вы делаете фундаментально бессмысленные вещи (начиная с 10k потоков).
Исходная версия bugfixer, :
Есть у кого-нибудь теоритические познания - которые могут объяснить в чём может быть дело?
Даже не знаю с чего и начать. Неправильно всё, начиная с постановки вопроса и заканчивая методикой измерений. Если изначально IO-bound workload неожиданно становится CPU-bound (а уж тем более congested on a single mutex) - Вы что-то делаете фундаментально неправильно.
Если задача добиться максимума TPS - надо стараться держать все CQ Ваших SSD busy. И это выходит очень далеко за рамки дискуссии у mutex’ах.
Настоящая параллельная запись (с точки зрения прогаммы, а не диска конечно) вернется в программу тогда когда в наборе активных файлов останется 30
Управление в апликуху вернётся в момент когда ядро получит данные, а не когда они упадут на диск. Flushes - отдельная история.
Конечно в реальной работе этого кода никогда не будет в принципе более 3 потоков
Почему мы тогда вообще это обсуждаем?
Но вот просто очень интересно во первых почему возникает такая разница
Алгоритм крив донельзя.
Отпускает мьютекс, от котрый один на всех
Жесть.
спит 10 миллисекнуд
Double жесть.
сколько открыто файлов и список, с левого конца которого будет файл в который дольше всего не писали
Грамотный IO-scheduling - это искусство. Повторюсь - я уверен Вы делаете фундаментально бессмысленные вещи (начиная с 10k потоков).