From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [PATCH v2 repost 3/7] mm: add a function to get the max pfn Date: Wed, 27 Jul 2016 15:52:06 -0700 Message-ID: <57993B16.5010703@intel.com> References: <1469582616-5729-1-git-send-email-liang.z.li@intel.com> <1469582616-5729-4-git-send-email-liang.z.li@intel.com> <20160728010729-mutt-send-email-mst@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, virtio-dev@lists.oasis-open.org, kvm@vger.kernel.org, qemu-devel@nongnu.org, dgilbert@redhat.com, quintela@redhat.com, Andrew Morton , Vlastimil Babka , Mel Gorman , Paolo Bonzini , Cornelia Huck , Amit Shah To: "Michael S. Tsirkin" , Liang Li Return-path: In-Reply-To: <20160728010729-mutt-send-email-mst@kernel.org> Sender: owner-linux-mm@kvack.org List-Id: kvm.vger.kernel.org On 07/27/2016 03:08 PM, Michael S. Tsirkin wrote: >> > +unsigned long get_max_pfn(void) >> > +{ >> > + return max_pfn; >> > +} >> > +EXPORT_SYMBOL(get_max_pfn); >> > + > > This needs a coment that this can change at any time. > So it's only good as a hint e.g. for sizing data structures. Or, if we limit the batches to 1GB like you suggested earlier, then we might not even need this exported. It would mean that in the worst case, we temporarily waste 28k out of the 32k allocation for a small VM that had <128MB of memory. That seems like a small price to pay for not having to track max_pfn anywhere. -- 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