[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B7F05BA.4080903@redhat.com>
Date: Fri, 19 Feb 2010 16:42:18 -0500
From: Rik van Riel <riel@...hat.com>
To: Mel Gorman <mel@....ul.ie>
CC: Andrea Arcangeli <aarcange@...hat.com>,
Christoph Lameter <cl@...ux-foundation.org>,
Adam Litke <agl@...ibm.com>, Avi Kivity <avi@...hat.com>,
David Rientjes <rientjes@...gle.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 03/12] mm: Share the anon_vma ref counts between KSM and
page migration
On 02/18/2010 01:02 PM, Mel Gorman wrote:
> struct anon_vma {
> spinlock_t lock; /* Serialize access to vma list */
> -#ifdef CONFIG_KSM
> - atomic_t ksm_refcount;
> -#endif
> -#ifdef CONFIG_MIGRATION
> - atomic_t migrate_refcount;
> +#if defined(CONFIG_KSM) || defined(CONFIG_MIGRATION)
> +
> + /*
> + * The refcount is taken by either KSM or page migration
> + * to take a reference to an anon_vma when there is no
> + * guarantee that the vma of page tables will exist for
> + * the duration of the operation. A caller that takes
> + * the reference is responsible for clearing up the
> + * anon_vma if they are the last user on release
> + */
> + atomic_t refcount;
Calling it just refcount is probably confusing, since
the anon_vma is also referenced by being on the chain
with others.
Maybe "other_refcount" because it is refcounts taken
by things other than VMAs? I am sure there is a better
name possible...
--
All rights reversed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists