All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/7] mm: vmscan: Convert lumpy_mode into a bitmask
Date: Wed, 1 Dec 2010 12:21:16 +0100	[thread overview]
Message-ID: <20101201112116.GR15564@cmpxchg.org> (raw)
In-Reply-To: <20101201105029.GL13268@csn.ul.ie>

On Wed, Dec 01, 2010 at 10:50:29AM +0000, Mel Gorman wrote:
> On Wed, Dec 01, 2010 at 11:27:32AM +0100, Johannes Weiner wrote:
> > On Mon, Nov 22, 2010 at 03:43:50PM +0000, Mel Gorman wrote:
> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -51,11 +51,20 @@
> > >  #define CREATE_TRACE_POINTS
> > >  #include <trace/events/vmscan.h>
> > >  
> > > -enum lumpy_mode {
> > > -	LUMPY_MODE_NONE,
> > > -	LUMPY_MODE_ASYNC,
> > > -	LUMPY_MODE_SYNC,
> > > -};
> > > +/*
> > > + * lumpy_mode determines how the inactive list is shrunk
> > > + * LUMPY_MODE_SINGLE: Reclaim only order-0 pages
> > > + * LUMPY_MODE_ASYNC:  Do not block
> > > + * LUMPY_MODE_SYNC:   Allow blocking e.g. call wait_on_page_writeback
> > > + * LUMPY_MODE_CONTIGRECLAIM: For high-order allocations, take a reference
> > > + *			page from the LRU and reclaim all pages within a
> > > + *			naturally aligned range
> > 
> > I find those names terribly undescriptive.  It also strikes me as an
> > odd set of flags.  Can't this be represented with less?
> > 
> > 	LUMPY_MODE_ENABLED
> > 	LUMPY_MODE_SYNC
> > 
> > or, after the rename,
> > 
> > 	RECLAIM_MODE_HIGHER	= 1
> > 	RECLAIM_MODE_SYNC	= 2
> > 	RECLAIM_MODE_LUMPY	= 4
> > 
> 
> My problem with that is you have to infer what the behaviour is from what the
> flags "are not" as opposed to what they are. For example, !LUMPY_MODE_SYNC
> implies LUMPY_MODE_ASYNC instead of specifying LUMPY_MODE_ASYNC.

Sounds like a boolean value to me.  And it shows: you never actually
check for RECLAIM_MODE_ASYNC in the code, you just always set it to
the opposite of RECLAIM_MODE_SYNC - the flag which is actually read.

> It also looks very odd when trying to distinguish between order-0
> standard reclaim, lumpy reclaim and reclaim/compaction.

That is true, because this is still an actual tristate.  It's probably
better to defer until lumpy reclaim is gone and there is only one flag
for higher-order reclaim left.

> > > +typedef unsigned __bitwise__ lumpy_mode;
> > 
> > lumpy_mode_t / reclaim_mode_t?
> > 
> 
> It can't hurt!

Thanks :)

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Weiner <hannes@cmpxchg.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/7] mm: vmscan: Convert lumpy_mode into a bitmask
Date: Wed, 1 Dec 2010 12:21:16 +0100	[thread overview]
Message-ID: <20101201112116.GR15564@cmpxchg.org> (raw)
In-Reply-To: <20101201105029.GL13268@csn.ul.ie>

On Wed, Dec 01, 2010 at 10:50:29AM +0000, Mel Gorman wrote:
> On Wed, Dec 01, 2010 at 11:27:32AM +0100, Johannes Weiner wrote:
> > On Mon, Nov 22, 2010 at 03:43:50PM +0000, Mel Gorman wrote:
> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -51,11 +51,20 @@
> > >  #define CREATE_TRACE_POINTS
> > >  #include <trace/events/vmscan.h>
> > >  
> > > -enum lumpy_mode {
> > > -	LUMPY_MODE_NONE,
> > > -	LUMPY_MODE_ASYNC,
> > > -	LUMPY_MODE_SYNC,
> > > -};
> > > +/*
> > > + * lumpy_mode determines how the inactive list is shrunk
> > > + * LUMPY_MODE_SINGLE: Reclaim only order-0 pages
> > > + * LUMPY_MODE_ASYNC:  Do not block
> > > + * LUMPY_MODE_SYNC:   Allow blocking e.g. call wait_on_page_writeback
> > > + * LUMPY_MODE_CONTIGRECLAIM: For high-order allocations, take a reference
> > > + *			page from the LRU and reclaim all pages within a
> > > + *			naturally aligned range
> > 
> > I find those names terribly undescriptive.  It also strikes me as an
> > odd set of flags.  Can't this be represented with less?
> > 
> > 	LUMPY_MODE_ENABLED
> > 	LUMPY_MODE_SYNC
> > 
> > or, after the rename,
> > 
> > 	RECLAIM_MODE_HIGHER	= 1
> > 	RECLAIM_MODE_SYNC	= 2
> > 	RECLAIM_MODE_LUMPY	= 4
> > 
> 
> My problem with that is you have to infer what the behaviour is from what the
> flags "are not" as opposed to what they are. For example, !LUMPY_MODE_SYNC
> implies LUMPY_MODE_ASYNC instead of specifying LUMPY_MODE_ASYNC.

Sounds like a boolean value to me.  And it shows: you never actually
check for RECLAIM_MODE_ASYNC in the code, you just always set it to
the opposite of RECLAIM_MODE_SYNC - the flag which is actually read.

> It also looks very odd when trying to distinguish between order-0
> standard reclaim, lumpy reclaim and reclaim/compaction.

That is true, because this is still an actual tristate.  It's probably
better to defer until lumpy reclaim is gone and there is only one flag
for higher-order reclaim left.

> > > +typedef unsigned __bitwise__ lumpy_mode;
> > 
> > lumpy_mode_t / reclaim_mode_t?
> > 
> 
> It can't hurt!

Thanks :)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-12-01 11:21 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-22 15:43 [PATCH 0/7] Use memory compaction instead of lumpy reclaim during high-order allocations V2 Mel Gorman
2010-11-22 15:43 ` Mel Gorman
2010-11-22 15:43 ` [PATCH 1/7] mm: compaction: Add trace events for memory compaction activity Mel Gorman
2010-11-22 15:43   ` Mel Gorman
2010-11-22 15:43 ` [PATCH 2/7] mm: vmscan: Convert lumpy_mode into a bitmask Mel Gorman
2010-11-22 15:43   ` Mel Gorman
2010-12-01 10:27   ` Johannes Weiner
2010-12-01 10:27     ` Johannes Weiner
2010-12-01 10:50     ` Mel Gorman
2010-12-01 10:50       ` Mel Gorman
2010-12-01 11:21       ` Johannes Weiner [this message]
2010-12-01 11:21         ` Johannes Weiner
2010-12-01 11:56         ` Mel Gorman
2010-12-01 11:56           ` Mel Gorman
2010-12-02 11:04           ` Johannes Weiner
2010-12-02 11:04             ` Johannes Weiner
2010-12-02 12:03     ` [PATCH] mm: vmscan: Rename lumpy_mode to reclaim_mode fix Mel Gorman
2010-12-02 12:03       ` Mel Gorman
2010-11-22 15:43 ` [PATCH 3/7] mm: vmscan: Reclaim order-0 and use compaction instead of lumpy reclaim Mel Gorman
2010-11-22 15:43   ` Mel Gorman
2010-12-01 10:27   ` Johannes Weiner
2010-12-01 10:27     ` Johannes Weiner
2010-12-01 10:56     ` Mel Gorman
2010-12-01 10:56       ` Mel Gorman
2010-12-01 11:32       ` Johannes Weiner
2010-12-01 11:32         ` Johannes Weiner
2010-11-22 15:43 ` [PATCH 4/7] mm: migration: Allow migration to operate asynchronously and avoid synchronous compaction in the faster path Mel Gorman
2010-11-22 15:43   ` Mel Gorman
2010-12-01 10:28   ` Johannes Weiner
2010-12-01 10:28     ` Johannes Weiner
2010-11-22 15:43 ` [PATCH 5/7] mm: migration: Cleanup migrate_pages API by matching types for offlining and sync Mel Gorman
2010-11-22 15:43   ` Mel Gorman
2010-12-01 10:28   ` Johannes Weiner
2010-12-01 10:28     ` Johannes Weiner
2010-11-22 15:43 ` [PATCH 6/7] mm: compaction: Perform a faster migration scan when migrating asynchronously Mel Gorman
2010-11-22 15:43   ` Mel Gorman
2010-12-01 10:31   ` Johannes Weiner
2010-12-01 10:31     ` Johannes Weiner
2010-11-22 15:43 ` [PATCH 7/7] mm: vmscan: Rename lumpy_mode to reclaim_mode Mel Gorman
2010-11-22 15:43   ` Mel Gorman
2010-12-01 10:34   ` Johannes Weiner
2010-12-01 10:34     ` Johannes Weiner
2010-11-22 16:01 ` [PATCH 0/7] Use memory compaction instead of lumpy reclaim during high-order allocations V2 Andrea Arcangeli
2010-11-22 16:01   ` Andrea Arcangeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101201112116.GR15564@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.