> I've made a little progress fighting with bdflush. Can you please
> try this and see if it helps you? I have still to figure out why,
> but here, the first bdflush param _must_ be over 75 and under 90
> to avoid zillions of context switches. That alone will probably
> help enough, but I still think bdflush needs to do what the comments
> say too.
I sent this email a few days ago, but got no response. Can one of the mm
guys (Rik, Andrea?) please comment?
Anton
-----
> bdflush is broken in current kernels. I posted to linux-mm about this,
> but Rik et al haven't shown any interest. I normally see bursts of
> up to around 40K cs/second when doing writes; I hacked a little
> premption counter into the kernel and verified that they're practially
> all bdflush...
I found that during a dbench run we were calling bdflush to synchronously
flush out buffers too early. Changing nfract in /proc/sys/vm/bdflush from
40 to 100 improved this a lot.
Looking at the code we seem to be doubling the number of dirty buffers
(dirty *= 200). Can someone explain this?
Anton
int balance_dirty_state(kdev_t dev)
{
unsigned long dirty, tot, hard_dirty_limit, soft_dirty_limit;
int shortage;
dirty = size_buffers_type[BUF_DIRTY] >> PAGE_SHIFT;
tot = nr_free_buffer_pages();
dirty *= 200;
soft_dirty_limit = tot * bdf_prm.b_un.nfract;
hard_dirty_limit = soft_dirty_limit * 2;
/* First, check for the "real" dirty limit. */
if (dirty > soft_dirty_limit) {
if (dirty > hard_dirty_limit)
return 1;
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
