In article <[EMAIL PROTECTED]>,
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>i'm seeing similar problems. I think these problems started when the
>elevator was rewritten, i believe it broke the proper unplugging of IO
>devices. Does your performance problem get fixed by the attached
>workaround?
If this helps, that implies that somebody is doing a (critical) IO
request, without ever actually asking for the request to be _started_.
That sounds like a bug, and the patch looks like band-aid.
Where do we end up scheduling without starting the disk IO?
I'd rather add the disk schedule to _that_ place, instead of adding it
to every re-schedule event.
(For example, on a multi-CPU system it should _not_ be the case that one
CPU scheduling frequently should cause IO performance to go down - yet
your patch will do exactly that).
Could you make it print out a backtrace instead when this happens (make
it do it for the first few times, so as not to flood your console
forever if it ends up being common..)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
