Re: IO scheduler, queue depth, nr_requests

[Nick Piggin]

Miquel van Smoorenburg wrote:

> On Thu, 19 Feb 2004 23:52:32, Nick Piggin wrote:
>
> > Miquel van Smoorenburg wrote:
...

> > > Note that this is not an issue of '2 processes writing to 1 file', really.
> > > It's one process and pdflush writing the same dirty pages of the same file.
> > pdflush is a process though, that's all that matters.
>
> I understand that when the two processes are unrelated, the patch as I
> sent it will do the wrong thing.
>
> But the thing is, you get this:
>
> - "dd" process writes requests
> - pdflush triggers to write dirty pages
> - too many pages are dirty so "dd" blocks as well to write synchronously
> - "dd" process triggers "queue full" but gets marked as "batching" so
>  can continue (get_request)
> - pdflush tries to submit one bio and gets blocked (get_request_wait)
> - "dd" continues, but that one bio from pdflush remains stuck for a while

The batching logic can probably all be ripped out with per
process limits. It's too complex anyway really.

> That's stupid, that one bio from pdflush should really be allowed on
> the queue, since "dd" is adding requests from the same source to it
> anyway.

But the whole reason it is getting blocked in the first place
is because your controller is sucking up all your requests.
The whole problem is not a problem if you use properly sized
queues.

I'm a bit surprised that it wasn't working well with a controller
queue depth of 64 and 128 nr_requests. I'll give you a per process
request limit patch to try in a minute.

> Perhaps writes from pdflush should be handled differently to prevent
> this specific case ?
>
> Say, if pdflush adds request #128, don't mark it as batching, but
> let it block. The next process will be the one marked as batching
> and can continue. If pdflush tries to add a request > 128, allow it,
> but _then_ block it.
>
> Would something like that work ? Would it be a good idea to never mark
> a pdflush process as batching, or would that have a negative impact
> for some things ?

It's hard to know. Maybe a better solution would be to allow pdflush
to be exempt from the limits entirely as long as it tries not to write
to congested queues (which is what it does)...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/