Re: RFC for 2.6: avoid OOM at bounce buffer storm

[Martin Wilck]

Hello Andrew,

> The semaphore is initialised with the limit level, so once it has been
> down()ed more than `limit' times, processes will block until someone does
> up().

Oh - of course. Neat.

> > It appears to run much more 
> > smoothly now, perhaps because wakeup_bdflush() isn't called any more. 
> > Are you still interested in more data?
>
> Perhaps the newer kernel has writeback thresholding fixes so it's not
> possible to dirty as much memory with write().

I have collected more data and the behavior with 2.6.12-rc5-mm2 is 
flawless, there is a continuous writeback flow close to the maximum rate 
possible, and the bounce buffer usage never gets anywhere near the limit 
where it'd become dangerous. At least not in my test setup. The latest 
fedora kernel 2.6.11-1.27 also behaves ok, although it doesn't adapt to 
changing io load as smoothly as 2.6.12-rc5-mm2 does, and the writeback 
rate is oscillating more strongly.

The kernels where I observe the problem are 2.6.9 kernels from RedHat 
EL4. I have posted this here because I saw that the highmem bounce 
buffer/memory pool implementation was identical between the 2.6.9 kernel 
and all but the very latest development kernels, and I concluded 
prematurely that the behavior under my scenario must also be the same -- 
which it wasn't. I apologize for not having looked more closely.

Many thanks for looking into this anyway. From a theoretical point of 
view, I still think I had a valid point :-/.

Your patch sure looks good to me.

Regards
Martin

--
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1        mailto:Martin.Wilck@xxxxxxxxxxxxxxxxxxx
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy
-
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/