Subject: I/O priorities
To: Manuel Bouyer <bouyer@antioche.lip6.fr>
From: Aidan Cully <aidan@kublai.com>
List: tech-kern
Date: 06/20/2002 08:35:50
[redirected to tech-kern]
On Thu, Jun 20, 2002 at 01:06:58PM +0200, Manuel Bouyer wrote:
> On Thu, Jun 20, 2002 at 01:01:35PM +0200, Wojciech Puchar wrote:
> > i understand. can't we have 2 queues?
>
> This is what I'm saying since the begining :)
> Yes, we need to give different priorities to different I/O, and having several
> queues one way to do this (it may not be the best; if we want to keep disksort
> keeping a single queue may be easier). The problem is to define the
> priority policy (and eventually to gather some infos from upper layer to help
> implementing this policy).
I'm starting to understand this a bit better... Two things strike me
about this: 1) it's only a problem when the kernel allocates buffers
for its own internal use, during read()s and write()s, but not mmap().
2) The problem we'd be trying to solve is almost the same as that
originally faced by Berkeley when they created the scheduler system --
that is, to still allow a good level of interactivity when some
processes want to use all the CPU for themselves, though in this case
it's processes wanting to use all buffers and disk I/O.
Maybe an I/O scheduler makes sense as a solution to this problem? Or
would that be Too Much Effort? If so, another solution might be to
restrict the percentage of available buffers a given process can use
for read/write... Keep it small enough, and you wouldn't need to wait
seconds for dd if=/dev/zero to flush all of its buffers.
Just a thought... It's possible I've got a gross misunderstanding of
the issue.
--aidan