Re: blk_congestion_wait racy?

[Nick Piggin]

Martin Schwidefsky wrote:

> > Yes, sorry, all the world's an x86 :( Could you please send me whatever
> > diffs were needed to get it all going?
>
> I am just preparing that mail :-)
>
>
> > I thought you were running a 256MB machine?  Two seconds for 400 megs of
> > swapout?  What's up?
>
> Roughly 400 MB of swapout. And two seconds isn't that bad ;-)
>
>
> > An ouch-per-second sounds reasonable.  It could simply be that the CPUs
> > were off running other tasks - those timeout are less than scheduling
> > quanta.
>
> I don't understand why an ouch-per-second is reasonable. The mempig is
> the only process that runs on the machine and the blk_congestion_wait
> uses HZ/10 as timeout value. I'd expect about 100 ouches for the 10
> seconds the test runs.
>
> The 4x performance difference remains not understood.

It would still be blk_congestion_wait slowing things down, wouldn't
it? Performance was good when you took that out, wasn't it?

And it would not unusual for you to be waiting needlessly without
seeing the ouch.

I think I will try doing a non-racy blk_congestion_wait after Jens'
unplugging patch gets put into -mm. That should solve your problem.

-
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/