Re: 2.5.74-mm3 OOM killer fubared ?

[Miquel van Smoorenburg]

In article <Pine.LNX.4.53.0307100918410.203@chaos>,
Richard B. Johnson <[e-mail]> wrote:
>On Thu, 10 Jul 2003, Miquel van Smoorenburg wrote:
>
>> As I said I've got plenty memory free ... perhaps I need to tune
>> /proc/sys/vm because I've got so much streaming I/O ? Possibly,
>> there are too many dirty pages so cleaning them out faster might
>> help (and let pflushd do it instead of my single-threaded app)
>>

I did the tuning now, but it did not help much. Alas.

>The problem, as I see it, is that you can dirty pages 10-15 times
>faster than they can be written to disk. So, you will always
>have the possibility of an OOM situation as long as you are I/O
>bound. FYI, you can read/write RAM at 1,000+ megabytes/second, but
>you can only write to disk at 80 megabytes/second with the fastest
>SCSI around, 40 megabytes/second with ATA, 20 megabytes/second with
>IDE/DMA, 10 megabytes/second with PIOW, etc. There just aren't
>any disks around that will run at RAM speeds so buffered I/O will
>always result in full buffers if the I/O is sustained. To completely
>solve the OOM situation requires throttling the generation of data.

My disks are fast enough - under 2.5.74-vanilla, no problem.

>It is only when the data generation rate is less than or equal to
>the data storage rate that you can generate data forever.
>
>A possibility may be to not return control to the writing process
>(including swap), until the write completes if RAM gets low.

That's what can be tuned with /proc/sys/vm/dirty_ratio , right ?
If I understand Documentation/filesystems/proc.txt correctly.

Mike.