Attention is currently required from: jolly, pespin.
1 comment:
Patchset:
IMHO this shouldn't happen if we use a big-enough ring size. […]
this was based on a discussion aeversberg and I had before he started to wrok on the patch. The overflowing ring can happen with a lot of FDs that have so far one pending read-sqe, and which now might each have multiple sqe's each.
The application has no idea of the total number of fd's encountered during runtime. The library has even less of an idea. The sysadmin/operator might be able to estimate it, *if* they really understand a lot about the overall architecture and the need to statically size the SQE array. I'd argue 99% of the people operating our software might not be aware of such a requirement. So we should scale automatically, if needed.
Delaying a write will happen automatically via a queue. But if we cannot allocate a sqe for a read, how should we handle this via queueing? And as reads and writes share the same ring (and hence pool of SQE), we cannot prioritize reads over writes.
What is wrong about creating a new (larger) ring when detecting the current one is too small? That should be a super-rare event maybe once or so if load increases a lot. Afterwards the size is sufficient for future similar load scenarios during process runtime.
To view, visit change 40725. To unsubscribe, or for help writing mail filters, visit settings.