Messages in this thread | | | Subject | Re: 2.6.5-rc1-mm2 and direct_read_under and wb | From | Daniel McNeil <> | Date | 23 Mar 2004 13:38:01 -0800 |
| |
It looks like every place wbc->nonblocking is set to 1, sync_mode is set to WB_SYNC_NONE, but there are places where WB_SYNC_NONE is used and nonblocking is NOT set: balance_dirty_pages() try_to_unuse()
So your patch makes balance_dirty_pages() do the lock_buffer() in __block_write_full_page() instead of skipping and redirtying the page.
I just making sure I understand. So, WB_SYNC_ALL and nonblocking=1 should never be used?
Daniel
On Tue, 2004-03-23 at 09:59, Andrew Morton wrote: > Daniel McNeil <daniel@osdl.org> wrote: > > > > Andrew, > > > > Just to confirm my tests ran overnight without errors. > > good. > > > So the !wbc->nonblocking lowers the cpu utilization. > > yup. It prevents balance_dirty_pages() callers from spinning over the same > pages again and again. > > > What does sync_mode=WB_SYNC_ALL and nonblocking=1 mean? > > WB_SYNC_ALL means "we're performing this writeout for data-integrity > purposes, as opposed to for a regular dirty memory flush". The code paths > for these two things are deep, and are almost identical, so we pass it up > and down in a flag. > > ->nonblocking means "try to avoid blocking on request queues or locked > pages". pdflush and kswapd set this because those processes must serve > many queues and cannot accord to get stuck on any one queue. But regular > write() callers do not set ->nonblocking because we _want_ these guys to > throttle. > > It's only OK to let pdflush avoid blocking on the buffer because pdflush > will take an explicit nap in background_writeout(). hm, but only if the > queue is congested - we may still have a problem there.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |