From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [PATCH v2 repost 6/7] mm: add the related functions to get free page info Date: Wed, 27 Jul 2016 09:40:56 -0700 Message-ID: <5798E418.7080608@intel.com> References: <1469582616-5729-1-git-send-email-liang.z.li@intel.com> <1469582616-5729-7-git-send-email-liang.z.li@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: 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 , "Michael S. Tsirkin" , Paolo Bonzini , Cornelia Huck , Amit Shah To: Liang Li , linux-kernel@vger.kernel.org Return-path: In-Reply-To: <1469582616-5729-7-git-send-email-liang.z.li@intel.com> Sender: owner-linux-mm@kvack.org List-Id: kvm.vger.kernel.org On 07/26/2016 06:23 PM, Liang Li wrote: > + for_each_migratetype_order(order, t) { > + list_for_each(curr, &zone->free_area[order].free_list[t]) { > + pfn = page_to_pfn(list_entry(curr, struct page, lru)); > + if (pfn >= start_pfn && pfn <= end_pfn) { > + page_num = 1UL << order; > + if (pfn + page_num > end_pfn) > + page_num = end_pfn - pfn; > + bitmap_set(bitmap, pfn - start_pfn, page_num); > + } > + } > + } Nit: The 'page_num' nomenclature really confused me here. It is the number of bits being set in the bitmap. Seems like calling it nr_pages or num_pages would be more appropriate. Isn't this bitmap out of date by the time it's send up to the hypervisor? Is there something that makes the inaccuracy OK here? -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757149AbcG0Qk6 (ORCPT ); Wed, 27 Jul 2016 12:40:58 -0400 Received: from mga09.intel.com ([134.134.136.24]:60391 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754206AbcG0Qk5 (ORCPT ); Wed, 27 Jul 2016 12:40:57 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,430,1464678000"; d="scan'208";a="1025004074" Subject: Re: [PATCH v2 repost 6/7] mm: add the related functions to get free page info To: Liang Li , linux-kernel@vger.kernel.org References: <1469582616-5729-1-git-send-email-liang.z.li@intel.com> <1469582616-5729-7-git-send-email-liang.z.li@intel.com> Cc: 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 , "Michael S. Tsirkin" , Paolo Bonzini , Cornelia Huck , Amit Shah From: Dave Hansen Message-ID: <5798E418.7080608@intel.com> Date: Wed, 27 Jul 2016 09:40:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <1469582616-5729-7-git-send-email-liang.z.li@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/26/2016 06:23 PM, Liang Li wrote: > + for_each_migratetype_order(order, t) { > + list_for_each(curr, &zone->free_area[order].free_list[t]) { > + pfn = page_to_pfn(list_entry(curr, struct page, lru)); > + if (pfn >= start_pfn && pfn <= end_pfn) { > + page_num = 1UL << order; > + if (pfn + page_num > end_pfn) > + page_num = end_pfn - pfn; > + bitmap_set(bitmap, pfn - start_pfn, page_num); > + } > + } > + } Nit: The 'page_num' nomenclature really confused me here. It is the number of bits being set in the bitmap. Seems like calling it nr_pages or num_pages would be more appropriate. Isn't this bitmap out of date by the time it's send up to the hypervisor? Is there something that makes the inaccuracy OK here? From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58506) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSRtM-0003PT-N6 for qemu-devel@nongnu.org; Wed, 27 Jul 2016 12:41:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSRtI-0000LL-RT for qemu-devel@nongnu.org; Wed, 27 Jul 2016 12:41:08 -0400 Received: from mga02.intel.com ([134.134.136.20]:8641) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSRtI-0000LH-LY for qemu-devel@nongnu.org; Wed, 27 Jul 2016 12:41:04 -0400 References: <1469582616-5729-1-git-send-email-liang.z.li@intel.com> <1469582616-5729-7-git-send-email-liang.z.li@intel.com> From: Dave Hansen Message-ID: <5798E418.7080608@intel.com> Date: Wed, 27 Jul 2016 09:40:56 -0700 MIME-Version: 1.0 In-Reply-To: <1469582616-5729-7-git-send-email-liang.z.li@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 repost 6/7] mm: add the related functions to get free page info List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Liang Li , linux-kernel@vger.kernel.org Cc: 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 , "Michael S. Tsirkin" , Paolo Bonzini , Cornelia Huck , Amit Shah On 07/26/2016 06:23 PM, Liang Li wrote: > + for_each_migratetype_order(order, t) { > + list_for_each(curr, &zone->free_area[order].free_list[t]) { > + pfn = page_to_pfn(list_entry(curr, struct page, lru)); > + if (pfn >= start_pfn && pfn <= end_pfn) { > + page_num = 1UL << order; > + if (pfn + page_num > end_pfn) > + page_num = end_pfn - pfn; > + bitmap_set(bitmap, pfn - start_pfn, page_num); > + } > + } > + } Nit: The 'page_num' nomenclature really confused me here. It is the number of bits being set in the bitmap. Seems like calling it nr_pages or num_pages would be more appropriate. Isn't this bitmap out of date by the time it's send up to the hypervisor? Is there something that makes the inaccuracy OK here?