История изменений

интересно... А не будет ли этих буферов слишком много? А в каком месте они мержатся в реальные очереди к устройствам?

Как в blk-mq. Пишется ядерная прослойка, которая создает массив из N per-cpu очередей. Когда приложение засылает реквест, прослойка кладет реквест в очередь (под nopreempt) и дергает твоей FS нотификатор. Твоя FS спрашивает через ioctl() список операций из конкретной очереди и обрабатывает их. Ну или через read(), не суть важно.

это кто делает? В рамках разработки FUSE драйвера или глубже уже в где-то в ядре?

В userspace :) Создаешь тред, который говорит ioctl'м «хочу, чтобы ты меня привязал к такой-то очереди». Ему возвращают eventfd от этой очереди, по которой же и аккаунтинг на выдачу данных делается.

Мы с чуваками такое для блочного драйвера в US делали, работало с очень небольшой добавленной латентностью. Порядка пары сотен микросекунд вроде. Я могу перепроверить попозже, у меня код остался :)

интересно... А не будет ли этих буферов слишком много? А в каком месте они мержатся в реальные очереди к устройствам?

Как в blk-mq. Пишется ядерная прослойка, которая создает массив из N per-cpu очередей. Когда приложение засылает реквест, прослойка кладет реквест в очередь (под nopreempt) и дергает твоей FS нотификатор. Твоя FS спрашивает через ioctl() список операций из конкретной очереди и обрабатывает их. Ну или через read(), не суть важно.

это кто делает? В рамках разработки FUSE драйвера или глубже уже в где-то в ядре?

В userspace :) Создаешь тред, который говорит ioctl'м «хочу, чтобы ты меня привязал к такой-то очереди». Ему возвращают eventfd от этой очереди, по которой же и аккаунтинг на выдачу данных делается.

Мы с чуваками такое для блочного драйвера в US делали, работало с очень небольшой добавленной латентностью. Порядка сотни микросекунд вроде. Я могу перепроверить попозже, у меня код остался :)

интересно... А не будет ли этих буферов слишком много? А в каком месте они мержатся в реальные очереди к устройствам?

Как в blk-mq. Пишется ядерная прослойка, которая создает массив из N per-cpu очередей. Когда приложение засылает реквест, прослойка кладет реквест в очередь (под nopreempt) и дергает твоей FS нотификатор. Твоя FS спрашивает через ioctl() список операций из конкретной очереди и обрабатывает их. Ну или через read(), не суть важно.

это кто делает? В рамках разработки FUSE драйвера или глубже уже в где-то в ядре?

В userspace :) Создаешь тред, который говорит ioctl'м «хочу, чтобы ты меня привязал к такой-то очереди». Ему возвращают eventfd от этой очереди, по которой же и аккаунтинг на выдачу данных делается.

интересно... А не будет ли этих буферов слишком много? А в каком месте они мержатся в реальные очереди к устройствам?

Как в blk-mq. Пишется ядерная прослойка, которая создает массив из N per-cpu очередей. Когда приложение засылает реквест, прослойка кладет реквест в очередь (под nopreempt) и дергает твоей FS нотификатор. Твоя FS спрашивает через ioctl() список операций из конкретной очереди и обрабатывает их. Ну или через read(), не суть важно.

это кто делает? В рамках разработки FUSE драйвера или глубже уже в где-то в ядре?

В userspace :) Создаешь тред, который говорит ioctl'м «хочу, чтобы ты меня привязал к такой-то очереди».