Messages in this thread |  | | Date | Tue, 24 Oct 2000 21:29:32 -0700 | Subject | Re: 2.4.0-test10pre5: still IDE lockups on HPT366 controller. | From | Anton Blanchard <> |
| |
> 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |