On Wed, Nov 23, 2011 at 11:08 PM, Mel Gorman <mgorman@xxxxxxx> wrote: > On Wed, Nov 23, 2011 at 10:35:37PM +0800, Nai Xia wrote: >> On Wed, Nov 23, 2011 at 9:45 PM, Mel Gorman <mgorman@xxxxxxx> wrote: >> > On Wed, Nov 23, 2011 at 09:05:08PM +0800, Nai Xia wrote: >> >> > <SNIP> >> >> > >> >> > 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, >> > >> > Why would it be necessary? >> > Why would it be better than what is there now? >> >> I mean, if >> MIGRATE_SYNC_LIGHT --> (current->flags & PF_MEMALLOC) and >> MIGRATE_SYNC_LIGHT --> no dirty writeback, and (current->flags & PF_MEMALLOC) >> --> (MIGRATE_SYNC_LIGHT || MIGRATE_ASYNC) >> MIGRATE_ASYNC --> no dirty writeback, then >> why not simply (current->flags & PF_MEMALLOC) ---> no dirty writeback >> and keep the sync meaning as it was? >> > > Ok, I see what you mean. Instead of making MIGRATE_SYNC_LIGHT part of > the API, we could instead special case within migrate.c how to behave if > MIGRATE_SYNC && PF_MEMALLOC. Yeah~ > > This would be functionally equivalent and satisfy THP users > but I do not see it as being easier to understand or easier > to maintain than updating the API. If someone in the future > wanted to use migration without significant stalls without > being PF_MEMALLOC, they would need to update the API like this. > There are no users like this today but automatic NUMA migration > might want to leverage something like MIGRATE_SYNC_LIGHT > (http://comments.gmane.org/gmane.linux.kernel.mm/70239) I see. So could I say that might be the time and users for my suggestion of page uptodate check to fit into? Thanks, Nai > > -- > Mel Gorman > SUSE Labs > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href