Re: O_DIRECT question

[Bill Davidsen <davidsen@tmr.com>]

Nick Piggin wrote:
> Aubrey wrote:
>> On 1/11/07, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
>>> What you _really_ want to do is avoid large mallocs after boot, or use
>>> a CPU with an mmu. I don't think nommu linux was ever intended to be a
>>> simple drop in replacement for a normal unix kernel.
>>
>>
>> Is there a position available working on mmu CPU? Joking, :)
>> Yes, some problems are serious on nommu linux. But I think we should
>> try to fix them not avoid them.
> 
> Exactly, and the *real* fix is to modify userspace not to make > PAGE_SIZE
> mallocs[*] if it is to be nommu friendly. It is the kernel hacks to do 
> things
> like limit cache size that are the bandaids.

Tuning the system to work appropriately for a given load is not a 
band-aid. I have been saying since 2.5.x times that filling memory with 
cached writes was a bad thing, and filling with writes to a single file 
was a doubly bad thing. Back in 2.4.NN-aa kernels, there were some 
tunables to address that, but other than adding your own 2.6 just 
behaves VERY badly for some loads.
> 
> Of course, being an embedded system, if they work for you then that's
> really fine and you can obviously ship with them. But they don't need to
> go upstream.
> 
Anyone who has a few processes which write a lot of data and many 
processes with more modest i/o needs will see the overfilling of cache 
with data from one process or even for one file, and the resulting 
impact on the performance of all other processes, particularly if the 
kernel decides to write all the data for one file at once, because it 
avoids seeks, even if it uses the drive for seconds. The code has gone 
too far in the direction of throughput, at the expense of response to 
other processes, given the (common) behavior noted.

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979