[lkml]   [2000]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: elevator-starvation-4 (2.2.14 && 2.3.42)

On Fri, 11 Feb 2000 06:10:37 -0800, Bruce Thompson
<> said:

> Well, yes and no. I guess my fundamental claim is that if
> userland is able to generate requests faster than the driver can
> fulfill them for an extended period of time then we've got a larger
> problem than worrying about a particular request taking a long time to
> satisfy. Indeed, I claim that as long as the driver cannot keep up
> there will always be a pathological case where a particular request is
> unreasonably delayed.

> I'm not saying I have any idea what the correct solution is, but I
> feel that tackling the request scheduling problem is less meaningful
> if we haven't at least taken a whack at solving the request overrun
> problem.

But we _have_ addressed request overrun. You are confusing two related
but quite distinct things: the flow control you refer to is simply not
done at the request layer at all, but rather at a higher level

First of all, user space generally does not create unbounded oustanding
IO request. It can generate unbounded dirty data, but that's something
different. Dirty data is cached for future writeback to disk, but that
writeback is not under the application's control (unless the user is
doing synchronous IO, in which case we have an obvious flow control
mechanism through which the application's performance will be

So, when an application is doing a lot of writing, we need to perform
flow control to throttle the amount of dirty data allowed at once. That
is already done, but it has nothing to do with the IO scheduling.

Once the writeback of that dirty data commences, _then_ we need to do IO
scheduling. In fact, Linux does this in two stages: the bdflush code
queues IO for dirty buffers without any fancy elevator sorting at all;
and then the IO layer services those outstanding IO requests using the
elevator sort.


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

 \ /
  Last update: 2005-03-22 13:56    [W:0.162 / U:17.852 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site