Possible to specify ioprio for reads and writes?

[manishrjain]

I'd like to set an kernel level i/o priority, so the reads get priority over the writes. Is that something that can be supported via zio public APIs? The easiest way I could come up with was to hack into zio and set sqe.ioprio = ... in the submit function in io_uring.zig (for Linux) -- but that applies way more broadly than I'd like.

[lalinsky]

Hm, I didn't know io_uring support I/O priorities, so no this is not supported yet.

I see two options:

1. We change stream.read() to receive options instead of timeout, and priority will be part of the options.

2. We add reader.setPriority() and writer.setPriority(), so all reads/writes in that reader/writer will have that particular priority set.

I'll need to do a bit more research on the topic. I'm really not sure whether I want to change the signature for a Linux-only feature.

[lalinsky]

OH, this only applies to file I/O?

I'm open to suggestion, but I'm not particularly keen on making it prominent in the public API.

I've been considering having per-fd settings in the zio.ev layer, this could potentially live there. Or even global settings in the io_uring backend directly.

[manishrjain]

The problem with doing it as part of File metadata, is that typically DBs would open a file once and it would be owned by (say) a Table object. That Table object would be passed around to whoever needs it for reads -- that could be background workers or user facing workers. And if the priority is set at file level, then all these reads would get equal priority. So, it's best if the read priority is set per the read request, instead of at file level.

Though, it sounds like NVMe drives (and I'm guessing EBS volumes as well) might just ignore the priority, so it's unclear how well this priority system works.

[lalinsky]

I've opened a draft PR that does two things:

1. Add the field to the low-level operations, so it's possible to set it for every op individually.

2. Add the field to file reader/writer, so you can create ad-hoc readers/writers with different priorities.

I'm still not 100% convinced this should be merged, need to see if anyone actually uses this, but the draft PR is pretty much non-intrusive, so I'm OK with it.

[manishrjain]

How do you figure out usage to know if it's ready to merge? Should I fork this library, and merge the PR to use the feature?

[lalinsky]

How do you figure out usage to know if it's ready to merge? Should I fork this library, and merge the PR to use the feature?

If you tell me it's usable to you in that form, I'm happy to merge it.

[manishrjain]

I ended up using an app level bandwidth manager, which does more than what priority would do. So, we can close this issue.