> } > 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...
> }
> There's some strangness in bdflush(). The comment says:
>
> /*
> * If there are still a lot of dirty buffers around,
> * skip the sleep and flush some more. Otherwise, we
> * go to sleep waiting a wakeup.
> */
> if (!flushed || balance_dirty_state(NODEV) < 0) {
> run_task_queue(&tq_disk);
> schedule();
> }
to me, that says: we haven't succeeded in flushing anything,
and our balance looks OK, so unplug the disks and sleep. this logic
must have got accidentally inverted at some point.
I think we want to unplug if we've flushed and are low on memory:
if (flushed && balance_dirty_state(NODEV) >= 0)
> Which leads me to believe that the `<' should be either `==' or `<='. I
> tried it with the `<=' and it doesn't seem to be so bad...Here's a patch
> to see if it helps you?
definitely. actually, I think there's some major code rot in the tuning
logic of the VM. specifically, free_shortage() and inactive_shortage()
both return an int that tells you how many pages we're short. negative
returns mean we're not short. but all calls to these functions treat the
return as a boolean! so for example, the following is wrong:
if (can_get_io_locks && !launder_loop && free_shortage()) {
(vmscan.c:page_launder) should be "free_shortage > 0". there are
about a dozen other similar places, for which I'll shortly post a patch.
regards, mark hahn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:18 EST