From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0BACC3F2D2 for ; Mon, 2 Mar 2020 14:05:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C8CEB2166E for ; Mon, 2 Mar 2020 14:05:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583157928; bh=5JkJOLC8ZMBk6am+XSq1nWzBPzEVTkyA6WETCyudsvc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=EHz7DXdkasQ82/AULaCpgEUfSKb6q+hzHTpphsJcpHyaVbHKboayU6LOe/g5Hue0T aBFRGpjnHuOAiCWftWkpFuoOtu9gLf8FJeZ+hIfZblp0SBQRzomMJ+faNLEDNgm3Gq 1tQ6FeksnNHra1YAXupwf059W0jTiBwcKmQ9OHcQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727111AbgCBOF1 (ORCPT ); Mon, 2 Mar 2020 09:05:27 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:44495 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726926AbgCBOF1 (ORCPT ); Mon, 2 Mar 2020 09:05:27 -0500 Received: by mail-wr1-f67.google.com with SMTP id n7so4836831wrt.11; Mon, 02 Mar 2020 06:05:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=c0cAfvYrVEVBx2ds1ZgWYcF17eBb1NlP7kXSkGclbIo=; b=bWbAUaIsJ6Jw/9ZYdnK+x2LEq7mtL1GYOJthJMdigAqeppYlW1aktWI8TP4e9vfT13 UF7mj22xg1MR6rtXXBSokfaeAhBszLrk2TLJg8RHqLZ97DOjvlrSehTjK8i4Smp/hHwP 4257FHkSh+49nfDab8Zmgw4uNIRHfJb89Q7L6SMogKteE6QK7ZrD4lkfec0+vGB2W2aT etzBpiZjoSR6ceMVHLA+j2fwLMIHX4TB3bL3e4RGwnywLYV+CEN6C1mtDedfO2JCGFRc pnGbWoESc6z88aWWl940pQyQqBFHhu20pVXUZAcUmjOWCZanaSMTgnFUBT68geRYCGDJ PoaA== X-Gm-Message-State: APjAAAVRCSYtiuE+35YTyrCibDppl40KS2TBY7G1cQFsWwk/PGmRf617 ioEJhRPVXSNEGDiub9vgBtt+JFjo X-Google-Smtp-Source: APXvYqx0+M3slxS1twXYHQLKyE1HWK32dT4Uy4lzZdKaDxvmor7yMe0SVC8biQ097XaClUCOR5acbg== X-Received: by 2002:adf:e808:: with SMTP id o8mr17538359wrm.8.1583157923708; Mon, 02 Mar 2020 06:05:23 -0800 (PST) Received: from localhost (prg-ext-pat.suse.com. [213.151.95.130]) by smtp.gmail.com with ESMTPSA id q3sm15291876wmj.38.2020.03.02.06.05.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Mar 2020 06:05:22 -0800 (PST) Date: Mon, 2 Mar 2020 15:05:19 +0100 From: Michal Hocko To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, virtio-dev@lists.oasis-open.org, virtualization@lists.linux-foundation.org, kvm@vger.kernel.org, Andrew Morton , "Michael S . Tsirkin" , Vlastimil Babka , Oscar Salvador , Mel Gorman , Mike Rapoport , Dan Williams , Alexander Duyck , Pavel Tatashin , Alexander Potapenko Subject: Re: [PATCH v1 04/11] mm: Export alloc_contig_range() / free_contig_range() Message-ID: <20200302140519.GN4380@dhcp22.suse.cz> References: <20200302134941.315212-1-david@redhat.com> <20200302134941.315212-5-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200302134941.315212-5-david@redhat.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 02-03-20 14:49:34, David Hildenbrand wrote: > A virtio-mem device wants to allocate memory from the memory region it > manages in order to unplug it in the hypervisor - similar to > a balloon driver. Also, it might want to plug previously unplugged > (allocated) memory and give it back to Linux. alloc_contig_range() / > free_contig_range() seem to be the perfect interface for this task. > > In contrast to existing balloon devices, a virtio-mem device operates > on bigger chunks (e.g., 4MB) and only on physical memory it manages. It > tracks which chunks (subblocks) are still plugged, so it can go ahead > and try to alloc_contig_range()+unplug them on unplug request, or > plug+free_contig_range() unplugged chunks on plug requests. > > A virtio-mem device will use alloc_contig_range() / free_contig_range() > only on ranges that belong to the same node/zone in at least > MAX(MAX_ORDER - 1, pageblock_order) order granularity - e.g., 4MB on > x86-64. The virtio-mem device added that memory, so the memory > exists and does not contain any holes. virtio-mem will only try to allocate > on ZONE_NORMAL, never on ZONE_MOVABLE, just like when allocating > gigantic pages (we don't put unmovable data into the movable zone). Same feedback as in pxm_to_node export. No objections to exporting the symbol but it would be better to squash this function into the patch which uses it. The changelog is highly virtio-mem specific anyway. Maybe it is just a dejavu but I feel I have already said that but I do not remember any details. > Cc: Andrew Morton > Cc: Michal Hocko > Cc: Vlastimil Babka > Cc: Oscar Salvador > Cc: Mel Gorman > Cc: Mike Rapoport > Cc: Dan Williams > Cc: Alexander Duyck > Cc: Pavel Tatashin > Cc: Alexander Potapenko > Acked-by: Michal Hocko # to export contig range allocator API > Signed-off-by: David Hildenbrand > --- > mm/page_alloc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 79e950d76ffc..8d7be3f33e26 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -8597,6 +8597,7 @@ int alloc_contig_range(unsigned long start, unsigned long end, > pfn_max_align_up(end), migratetype); > return ret; > } > +EXPORT_SYMBOL(alloc_contig_range); > > static int __alloc_contig_pages(unsigned long start_pfn, > unsigned long nr_pages, gfp_t gfp_mask) > @@ -8712,6 +8713,7 @@ void free_contig_range(unsigned long pfn, unsigned int nr_pages) > } > WARN(count != 0, "%d pages are still in use!\n", count); > } > +EXPORT_SYMBOL(free_contig_range); > > /* > * The zone indicated has a new number of managed_pages; batch sizes and percpu > -- > 2.24.1 -- Michal Hocko SUSE Labs