Messages in this thread | | | Date | Fri, 08 Feb 2002 10:28:18 -0800 | From | Andrew Morton <> | Subject | Re: [patch] get_request starvation fix |
| |
Rik van Riel wrote: > > On Fri, 8 Feb 2002, Andrew Morton wrote: > > > + * This all assumes that the rate of taking requests is much, much higher > > + * than the rate of releasing them. Which is very true. > > This is not necessarily true for read requests. > > If each read request is synchronous and the process will > generate the next read request after the current one > has finished, then it's quite possible to clog up the > queue with read requests which are generated at exactly > the same rate as they're processed. > > Couldn't this still cause starvation, even with your patch?
No, that's fine.
The problem which the comment refers to is: how to provide per-process request batching without running off and creating per-process reservation pools or such.
What I'm relying on is that when a sleeper is woken (at low-water), there are at least (high-water - low-water) requests available before get_request will again sleep. And that the woken process will be able to grab a decent number of those non-blocking requests. I suspect it's always true, as long as (high-water - low_water) is "much greater than" the number of CPUs.
The synchronous reader is well-behaved, and should be nicely FIFO if we're getting low on requests.
- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |