From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752904AbdCQDmJ (ORCPT ); Thu, 16 Mar 2017 23:42:09 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:37676 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751321AbdCQDmI (ORCPT ); Thu, 16 Mar 2017 23:42:08 -0400 MIME-Version: 1.0 In-Reply-To: <94e0d115-7deb-c748-3dc2-60d6289e6551@nvidia.com> References: <1489680335-6594-1-git-send-email-jglisse@redhat.com> <1489680335-6594-8-git-send-email-jglisse@redhat.com> <20170316160520.d03ac02474cad6d2c8eba9bc@linux-foundation.org> <94e0d115-7deb-c748-3dc2-60d6289e6551@nvidia.com> From: Balbir Singh Date: Fri, 17 Mar 2017 14:42:05 +1100 Message-ID: Subject: Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4 To: John Hubbard Cc: Andrew Morton , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , "linux-kernel@vger.kernel.org" , linux-mm , Naoya Horiguchi , David Nellans , Evgeny Baskakov , Mark Hairgrove , Sherry Cheung , Subhash Gutti Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> Or make the HMM Kconfig feature 64BIT only by making it depend on 64BIT? >> > > Yes, that was my first reaction too, but these particular routines are > aspiring to be generic routines--in fact, you have had an influence there, > because these might possibly help with NUMA migrations. :) > Yes, I still stick to them being generic, but I'd be OK if they worked just for 64 bit systems. Having said that even the 64 bit works version work for upto physical sizes of 64 - PAGE_SHIFT which is a little limiting I think. One option is to make pfn's unsigned long long and do 32 and 64 bit computations separately Option 2, could be something like you said a. Define a __weak migrate_vma to return -EINVAL b. In a 64BIT only file define migrate_vma Option 3 Something totally different If we care to support 32 bit we go with 1, else option 2 is a good starting point. There might be other ways of doing option 2, like you've suggested Balbir From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f69.google.com (mail-wm0-f69.google.com [74.125.82.69]) by kanga.kvack.org (Postfix) with ESMTP id 083706B038B for ; Thu, 16 Mar 2017 23:42:08 -0400 (EDT) Received: by mail-wm0-f69.google.com with SMTP id c5so1565518wmi.0 for ; Thu, 16 Mar 2017 20:42:07 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com. [2a00:1450:400c:c09::234]) by mx.google.com with ESMTPS id 130si1355546wml.115.2017.03.16.20.42.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 20:42:06 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id t189so6269031wmt.1 for ; Thu, 16 Mar 2017 20:42:06 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <94e0d115-7deb-c748-3dc2-60d6289e6551@nvidia.com> References: <1489680335-6594-1-git-send-email-jglisse@redhat.com> <1489680335-6594-8-git-send-email-jglisse@redhat.com> <20170316160520.d03ac02474cad6d2c8eba9bc@linux-foundation.org> <94e0d115-7deb-c748-3dc2-60d6289e6551@nvidia.com> From: Balbir Singh Date: Fri, 17 Mar 2017 14:42:05 +1100 Message-ID: Subject: Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4 Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: John Hubbard Cc: Andrew Morton , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , "linux-kernel@vger.kernel.org" , linux-mm , Naoya Horiguchi , David Nellans , Evgeny Baskakov , Mark Hairgrove , Sherry Cheung , Subhash Gutti >> Or make the HMM Kconfig feature 64BIT only by making it depend on 64BIT? >> > > Yes, that was my first reaction too, but these particular routines are > aspiring to be generic routines--in fact, you have had an influence there, > because these might possibly help with NUMA migrations. :) > Yes, I still stick to them being generic, but I'd be OK if they worked just for 64 bit systems. Having said that even the 64 bit works version work for upto physical sizes of 64 - PAGE_SHIFT which is a little limiting I think. One option is to make pfn's unsigned long long and do 32 and 64 bit computations separately Option 2, could be something like you said a. Define a __weak migrate_vma to return -EINVAL b. In a 64BIT only file define migrate_vma Option 3 Something totally different If we care to support 32 bit we go with 1, else option 2 is a good starting point. There might be other ways of doing option 2, like you've suggested Balbir -- 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: email@kvack.org