From: Mel Gorman <mgorman@suse.de>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] mm: clean up zone flags
Date: Fri, 5 Sep 2014 11:20:44 +0100 [thread overview]
Message-ID: <20140905102044.GG17501@suse.de> (raw)
In-Reply-To: <20140902222653.GA20186@cmpxchg.org>
On Tue, Sep 02, 2014 at 06:26:53PM -0400, Johannes Weiner wrote:
> From 2420ad16df0634e073ad327f0f72472d9b03762b Mon Sep 17 00:00:00 2001
> From: Johannes Weiner <hannes@cmpxchg.org>
> Date: Tue, 2 Sep 2014 10:14:36 -0400
> Subject: [patch] mm: clean up zone flags
>
> Page reclaim tests zone_is_reclaim_dirty(), but the site that actually
> sets this state does zone_set_flag(zone, ZONE_TAIL_LRU_DIRTY), sending
> the reader through layers indirection just to track down a simple bit.
>
> Remove all zone flag wrappers and just use bitops against zone->flags
> directly. It's just as readable and the lines are barely any longer.
>
> Also rename ZONE_TAIL_LRU_DIRTY to ZONE_DIRTY to match ZONE_WRITEBACK,
> and remove the zone_flags_t typedef.
>
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> Acked-by: David Rientjes <rientjes@google.com>
I would have gone with making them ZONE_TAIL_DIRTY and ZONE_TAIL_WRITEBACK
because to me it's clearer what the flag means. ZONE_DIRTY can be
interpreted as "the zone has dirty pages" which is not what reclaim
cares about, it cares about dirty pages at the tail of the LRU. However,
I don't feel strongly enough to make a big deal about it so
Acked-by: Mel Gorman <mgorman@suse.de>
Thanks.
--
Mel Gorman
SUSE Labs
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: David Rientjes <rientjes@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch] mm: clean up zone flags
Date: Fri, 5 Sep 2014 11:20:44 +0100 [thread overview]
Message-ID: <20140905102044.GG17501@suse.de> (raw)
In-Reply-To: <20140902222653.GA20186@cmpxchg.org>
On Tue, Sep 02, 2014 at 06:26:53PM -0400, Johannes Weiner wrote:
> From 2420ad16df0634e073ad327f0f72472d9b03762b Mon Sep 17 00:00:00 2001
> From: Johannes Weiner <hannes@cmpxchg.org>
> Date: Tue, 2 Sep 2014 10:14:36 -0400
> Subject: [patch] mm: clean up zone flags
>
> Page reclaim tests zone_is_reclaim_dirty(), but the site that actually
> sets this state does zone_set_flag(zone, ZONE_TAIL_LRU_DIRTY), sending
> the reader through layers indirection just to track down a simple bit.
>
> Remove all zone flag wrappers and just use bitops against zone->flags
> directly. It's just as readable and the lines are barely any longer.
>
> Also rename ZONE_TAIL_LRU_DIRTY to ZONE_DIRTY to match ZONE_WRITEBACK,
> and remove the zone_flags_t typedef.
>
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> Acked-by: David Rientjes <rientjes@google.com>
I would have gone with making them ZONE_TAIL_DIRTY and ZONE_TAIL_WRITEBACK
because to me it's clearer what the flag means. ZONE_DIRTY can be
interpreted as "the zone has dirty pages" which is not what reclaim
cares about, it cares about dirty pages at the tail of the LRU. However,
I don't feel strongly enough to make a big deal about it so
Acked-by: Mel Gorman <mgorman@suse.de>
Thanks.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2014-09-05 10:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-02 14:27 [patch] mm: clean up zone flags Johannes Weiner
2014-09-02 14:27 ` Johannes Weiner
2014-09-02 21:42 ` David Rientjes
2014-09-02 21:42 ` David Rientjes
2014-09-02 22:26 ` Johannes Weiner
2014-09-02 22:26 ` Johannes Weiner
2014-09-05 10:20 ` Mel Gorman [this message]
2014-09-05 10:20 ` Mel Gorman
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=20140905102044.GG17501@suse.de \
--to=mgorman@suse.de \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.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.