Re: Feature proposal (scheduling related)

From: Greg Stark (
Date: Wed Jul 23 2003 - 09:47:46 EST writes:

> 2) There's a phenomenon called "starvation". See that 'find' command in your
> example? If mozilla is disk-hungry enough, bad I/O scheduling can mean that
> 'find' command will sit there *forever*, tying up resources the whole time.
> This can cause issues. For instance - if you've flagged 'mozilla' as the
> process that gets first shot at the disk, what do you do if you start paging to
> the swap area, and some OTHER process has to read a page in? What if that
> "other process" is the X server or your window manager? Think REALLY hard here
> - just saying "I'll renice them too" is NOT the right answer.. .;)

I'm sure it's a serious issue, and yet my network has QoS set up and the low
priority flows still eventually get through just fine even though it has much
lower bandwidth available than my disk controller.

I think it would be really cool to be able to control disk i/o with the same
level of flexibility as network i/o. I could see setting up cbq trees that can
key off things like whether it's paging, a blocking/nonblocking i/o, or a
nonblocking i/o. They could also see what user owns the process, and what
inode the process's executable image is.

I would just wonder about the overhead.


- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to More majordomo info at Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:49 EST