Messages in this thread | | | Date | Mon, 22 Oct 2007 02:05:59 -0700 | From | Andrew Morton <> | Subject | Re: forcing write-back from FS - again |
| |
On Mon, 22 Oct 2007 11:52:33 +0300 Artem Bityutskiy <dedekind@yandex.ru> wrote:
> > It _should_ be the case that the number of locked-and-dirty pages which > > writeback encounters is very small, so skipping locked pages during > > writeback-for-memory-flushing won't have any significant effect. The first > > step should be to add a new /proc/vmstat field to count these pages and > > then do broad testing (especially on blocksize<pagesize filesystems) to > > confirm the theory. > > > > We'll still need to synchronously lock the page in > > writeback-for-data-integrity mode though. > > Thanks for suggestion. It sounds as a separate big job to enhance existing > WB_SYNC_NONE. I've just introduced new WB mode, and it seems to work fine: > > diff --git a/include/linux/writeback.h b/include/linux/writeback.h > @@ -28,6 +28,7 @@ static inline int task_is_pdflush(struct task_struct *task) > */ > enum writeback_sync_modes { > WB_SYNC_NONE, /* Don't wait on anything */ > + WB_SYNC_NONE_PG,/* Don't wait on anything, don't touch locked pages */ > WB_SYNC_ALL, /* Wait on every mapping */ > WB_SYNC_HOLD, /* Hold the inode on sb_dirty for sys_sync() */ > };
It would be simpler/safer/saner to add a new bitflag to writeback_control and use that directly. The WB_SYNC_foo flags are a holdover from an earlier time and really should be made to go away, in favour of directly setting up an appropriate writeback_control.
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c > @@ -641,6 +641,10 @@ retry: > for (i = 0; i < nr_pages; i++) { > struct page *page = pvec.pages[i]; > > + if (wbc->sync_mode == WB_SYNC_NONE_PG && > + PageLocked(page)) > + continue; > + > > My only concern is - what if the page we skipped because of WB_SYNC_NONE_PG > will somehow loose its dirty TAG and will never be written-back? But it is > because of my poor knowledge of Linux MM internals. Could you please comment on > this?
Well it might lose its dirty tag, if the thread which has a lock on the page is about to write it out or truncate it. But that shouldn't concern you here.
The code you have there looks racy: if someone else locks the page in that little window after the PageLocked() test we'll still block in lock_page(). That's unlikely to happen in your application (apart from a remaining ab/ba scenario) but we should make it robust:
if (wbc->skip_locked_pages) { if (TestSetPageLocked(page)) continue; } else { lock_page(page); }
- 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/
| |