On Wed, 13 Sep 2000, Mitchell Blank Jr wrote:
> James Sutherland wrote:
> > In terms of latency, I'd suggest we aim to keep the device in use all the
> > time we have outstanding requests: every time the device is ready to
> > accept a request, we feed it the "next" one in the queue; until it is free
> > again, requests pile up in the queue, being sorted, merged etc.
> >
> > This should perform very well under light loads - requests just get passed
> > to the device as fast as they can be handled - and under very heavy loads
> > - we have a large queue in play, with plenty of scope for reordering,
> > merges etc.
>
> The "large queue" goes against the whole point of this exercise - that
> is that if there are many items in the "queue" being sorted then
> unlucky requests can end up waiting a long time to get serviced.
Yes, you need some sort of priority boost to avoid starving unlucky
processes. Tracking a sort of I/O goodness value may help here: if I fire
off a copy of a large file, and a "find /", the former will get much
higher throughput due to large consecutive reads. As it does so, though,
it reduces its own I/O priority; 'eventually' it will be below find, and
find gets some I/O bandwidth.
> You want to have some reasonable break-off point where you just
> decide to make an elevator swipe in order to avoid starving those
> requests.
Hrmm... not quite the system I had in mind. I specifically want to avoid
delaying any requests: when possible, we just pass requests straight to
the drive. The queue of outstanding requests only arises in the first
place when the drive is busy.
> Keep in mind that I'm using the word "queue" in a confusing manner
> here - we're talking about how much we'll try to elevator-sort in
> a go, not the actual queue of all requests. I've been calling this
> a queue because from a performance standpoint that's what it is,
> so I think it helps to think of the problem that way.
Ahh... I see. If we have a large enough backlog of requests that we can't
even elevator sort them fast enough, there's something very odd going
on. Still, I was planning to impose a maximum limit on the backlog - the
question is, what to do when that limit is reached??
> Oh yeah one other thing about huge elevator queues to think about
> (although its not too pertinant these days). A friend of mine had
> a job 15 years or so ago to working on a commercial UNIX flavor.
> They were having some severe I/O performance problems under high
> loads. The problem was that they were trying to sort and merge
> all the pending requests. When I/O was heavy this ended up
> chewing all the CPU time and the kernel wouldn't actually be
> able to keep up sending requests to the disk :-) However, keep
> in mind that this was int the bad-old-days when "hard drive"
> meant a rack-mount Eagle and the elevator was expected to consider
> things like head positioning and rotational speed when doing
> a sort...
LOL! My approach does avoid that, though. As a worst case, the elevator
just doesn't get a chance to sort anything: every request issues hits the
disk directly. If the disk is handling requests fast enough the CPU can't
keep up, we don't really want an elevator anyway...
So, in various scenarios:
* Light I/O - disk handling requests as they are issued. Disk may be idle
at times.
* Medium I/O - small backlog being elevator sorted as needed. Disk active
continuously, but all requests being handled OK.
* Heavy I/O - large backlog building up. Disk continuously active, some
processes may be starved or throttled, depending on priorities.
In the third case, sometimes we WILL want processes starved of I/O. If I
have three processes running - an MP3 player (high priority), a 'find' and
a low priority backup job, I DO want the backup job starved in favour of
the other two.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:21 EST