[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHGf_=pzxcr3Tvfip4a_fFX5xoAy00SNgKBOxGg65Ro9xAopwA@mail.gmail.com>
Date: Wed, 30 May 2012 15:46:05 -0400
From: KOSAKI Motohiro <kosaki.motohiro@...il.com>
To: Christoph Lameter <cl@...ux.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Andrew Morton <akpm@...gle.com>, Dave Jones <davej@...hat.com>,
Mel Gorman <mgorman@...e.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
stable@...r.kernel.org, hughd@...gle.com,
Andrew Morton <akpm@...ux-foundation.org>, andi@...stfloor.org
Subject: Re: [PATCH 2/6] mempolicy: Kill all mempolicy sharing
On Wed, May 30, 2012 at 3:41 PM, Christoph Lameter <cl@...ux.com> wrote:
> On Wed, 30 May 2012, kosaki.motohiro@...il.com wrote:
>
>> refcount will be decreased even though was not increased whenever alloc_page_vma()
>> is called. As you know, mere mbind(MPOL_MF_MOVE) calls alloc_page_vma().
>
> Most of these issues are about memory migration and shared memory. If we
> exempt shared memory from memory migration (after all that shared memory
> has its own distinct memory policies already!) then a lot of these issues
> wont arise.
The final point is, to make proper cow for struct mempolicy. but until
fixing cpuset
bindings issue, we can't use mempolicy sharing anyway.
Moreover, now most core piece of mempolicy life cycle, say split_vma()
and dup_mmap(), don't use mempolicy sharing. Only mbind() does.
Thus, this patch don't increase normal workload memory usage.
--
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