[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170316203253.755ab6180affcfa3a7a9a1ba@linux-foundation.org>
Date: Thu, 16 Mar 2017 20:32:53 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Jerome Glisse <jglisse@...hat.com>
Cc: John Hubbard <jhubbard@...dia.com>,
Balbir Singh <bsingharora@...il.com>,
linux-kernel@...r.kernel.org, linux-mm <linux-mm@...ck.org>,
Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
David Nellans <dnellans@...dia.com>,
Evgeny Baskakov <ebaskakov@...dia.com>,
Mark Hairgrove <mhairgrove@...dia.com>,
Sherry Cheung <SCheung@...dia.com>,
Subhash Gutti <sgutti@...dia.com>
Subject: Re: [HMM 07/16] mm/migrate: new memory migration helper for use
with device memory v4
On Thu, 16 Mar 2017 21:52:23 -0400 (EDT) Jerome Glisse <jglisse@...hat.com> wrote:
> The original intention was for it to be 64bit only, 32bit is a dying
> species and before splitting out hmm_ prefix from this code and moving
> it to be generic it was behind a 64bit flag.
>
> If latter one someone really care about 32bit we can only move to u64
I think that's the best compromise. If someone wants this on 32-bit
then they're free to get it working. That "someone" will actually be
able to test it, which you clearly won't be doing!
However, please do check that the impact of this patchset on 32-bit's
`size vmlinux' is minimal. Preferably zero.
Powered by blists - more mailing lists