Re: O_DIRECT question

From: Bill Davidsen
Date: Thu Jan 11 2007 - 21:48:22 EST


Nick Piggin wrote:
Aubrey wrote:
On 1/11/07, Nick Piggin <nickpiggin@xxxxxxxxxxxx> 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@xxxxxxx>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
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/