Messages in this thread | | | Date | Wed, 23 Nov 2011 21:05:08 +0800 | Subject | Re: [PATCH 7/7] mm: compaction: Introduce sync-light migration for use by compaction | From | Nai Xia <> |
| |
On Wed, Nov 23, 2011 at 7:00 PM, Mel Gorman <mgorman@suse.de> wrote: > On Wed, Nov 23, 2011 at 10:01:53AM +0800, Nai Xia wrote: >> On Tue, Nov 22, 2011 at 2:56 PM, Shaohua Li <shaohua.li@intel.com> wrote: >> > On Tue, 2011-11-22 at 02:36 +0800, Mel Gorman wrote: >> >> This patch adds a lightweight sync migrate operation MIGRATE_SYNC_LIGHT >> >> mode that avoids writing back pages to backing storage. Async >> >> compaction maps to MIGRATE_ASYNC while sync compaction maps to >> >> MIGRATE_SYNC_LIGHT. For other migrate_pages users such as memory >> >> hotplug, MIGRATE_SYNC is used. >> >> >> >> This avoids sync compaction stalling for an excessive length of time, >> >> particularly when copying files to a USB stick where there might be >> >> a large number of dirty pages backed by a filesystem that does not >> >> support ->writepages. >> > Hi, >> > from my understanding, with this, even writes >> > to /proc/sys/vm/compact_memory doesn't wait for pageout, is this >> > intended? >> > on the other hand, MIGRATE_SYNC_LIGHT now waits for pagelock and buffer >> > lock, so could wait on page read. page read and page out have the same >> > latency, why takes them different? >> >> So for the problem you raised, I think my suggestion to Mel is to adopt the >> following logic: >> >> if (!trylock_page(page) && !PageUptodate(page)) >> we are quite likely to block on read, so we >> depend on yet another MIGRATE_SYNC_MODE to decide >> if we really want to lock_page() and wait for this IO. >> >> How do you think ? >> > > Where are you adding this check? > > If you mean in __unmap_and_move(), the check is unnecessary unless > another subsystem starts using sync-light compaction. With this series, > only direct compaction cares about MIGRATE_SYNC_LIGHT. If the page is
But I am still a little bit confused that if MIGRATE_SYNC_LIGHT is only used by direct compaction and another mode can be used by it: MIGRATE_ASYNC also does not write dirty pages, then why not also do an (current->flags & PF_MEMALLOC) test before writing out pages, like we already did for the page lock condition, but adding a new mode instead?
> not up to date, it is also locked during the IO and unlocked after > setting Uptodate in the IO completion handler. > > As the page is locked, compaction will fail trylock_page, do the > PF_MEMALLOC check and bail as it is not safe for direct compaction > to call lock_page as the comment in __unmap_and_move explains. This > should avoid the stall. > > Did I misunderstand your suggestion? > > -- > Mel Gorman > SUSE Labs > -- 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/
| |