> >>>>> "BH" == Bernhard Heidegger <bheide@hyperwave.com> writes:
> BH> Imagine an application which has most of the (index) file pages in memory
> BH> and many of the pages are dirty. bdflush will flush the pages regularly,
> BH> but the pages will get dirty immediately again.
> BH> If you can be sure, that the power cannot fail the performance should be
> BH> much better without bdflush, because kflushd has to write pages only if
> BH> the system is running low on memory...
>
> The performance improvement comes when looking for free memory. In
> most cases bdflush's slow but steady writing of pages keeps buffers
> clean. When the application wants more memory with bdflush in the
> background unsually the pages it needs will be clean (because the I/O
> started before the application needed it), so they can just be dropped
> out of memory. Relying on kflushd means nothing is written until an
> application needs the memory and then it must wait until something is
> written to disk, which is much slower.
Not absolutely true. kflushd flushes dirty buffers not when they're
all dirty, but when percentage of dirty buffers goes above the
threshold. And that threshold is tunable, default value as of recent
kernels is 40%.
So even if kflushd didn't run in time, that only means you have *up*
to 40% of dirty buffers. Other 60% or more are clean.
We're here speaking of first parameter in /proc/sys/vm/bdflush. It was
60 initially, but lowered recently (few months ago, half a year?) due
to problems with buffers at that time.
>
> Further
> a) garanteeing no power failure is hard.
Here I entirely agree. UPS' cost much more than update/bdflush. :)
> b) generally there is so much data on the disk you must write it
> sometime, because you can't hold it all in memory.
Right.
> c) I have trouble imagining a case where a small file would be rewritten
> continually.
>
It happens. Otherwise we wouldn't need buffers at all. :)
Maybe only to achieve asynchrony.
Think of metadata, and operations of creating/deleting lots of files
in the directory, and similar. Imagine a busy news/proxy server.
-- Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr> --------------------------------------------------------------------- Recursive, adj.; see Recursive.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html