To: Valdis.Kletnieks@vt.edu
Cc: jimis@gmx.net, linux-kernel@vger.kernel.org
Subject: Re: Feature proposal (scheduling related)
References: <3F1E6A25.5030308@gmx.net>
	<200307231417.h6NEHoqj010244@turing-police.cc.vt.edu>
In-Reply-To: <200307231417.h6NEHoqj010244@turing-police.cc.vt.edu>
From: Greg Stark <gsstark@mit.edu>
Organization: The Emacs Conspiracy; member since 1992
Date: 23 Jul 2003 10:47:46 -0400
Message-ID: <87oezlqoz1.fsf@stark.dyndns.tv>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1506
Lines: 26


Valdis.Kletnieks@vt.edu 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.

-- 
greg

-
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/