Received: by 2002:a17:90a:9307:0:0:0:0 with SMTP id p7csp5143841pjo; Tue, 11 Feb 2020 04:49:54 -0800 (PST) X-Google-Smtp-Source: APXvYqyVXlJrTE1OrDzjKspqkWlFIV1wX/jJuEYzq6yuQabVCObToD5VT8ibaHZhm9QYWQPhwyh3 X-Received: by 2002:a9d:6e02:: with SMTP id e2mr5157254otr.194.1581425394471; Tue, 11 Feb 2020 04:49:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581425394; cv=none; d=google.com; s=arc-20160816; b=k4OIWGPsjeBinuwEereIIACUN7eCFrEf2CWOa8eIVFdED8OX0BYl0JC5f7zuuL3xPI HEyYM4Wyzt/HYE29TnblcyfXmgm2g62M5cwgINGWm5ibuwvS+0xVU3NLfkF+yIslt6tE kdIAu5jwxEEeD1N1k25iTLY/n5MA0a+YSTXZIzT2wzLbvHp2u3N/dYwKm0O17Iv0yOPF C4mCWbfpY3z7bdp+VNELqwyJ1X5uSCCWo7iknFrZzB5RRtDsQf+KVUehqO0J/Qvog+7z T/KtE7E8y1d7R/WGVtMinraxoczp17e8BMRSZdTeVYSS7UdQ2rh7QU1C4NXdCozIhYJD fJ1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=/aoK1QXCzMorlswoGVCOoMeDkLwKz3AeoTqS+YSOfSw=; b=U0/NkpK5VEVDGnRd0SwzWG/8CH4AkSZmeZF07nUXtdtaZRAawTaEd7zwpeChhlJV+m QH/XCEEytrVVvTY6LlrbI7jk0xtwDpmFf1reingfEJSak79KYEUtdwh7hcG2oxTi2tFD CU+4gitUFAo4Twvx7mIZJQ+psOcmAptQEhjzDgwI0Ak72hu9ar+mwSQBI8nnsGoDA+zd B5Os3SAigs8Wj2/Bep9ZD19dCIFINm4wphNGiXyp/lbHMGB+EuccFvNwMSe5WP6pCFGt qCSYVN5Xut9Id0lGIoQwj2dpKDxLkH5mqS5nuzrYggvsw6z5FjZq5/xhRVrx7rAy5OTg drxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fqZNEJG0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 107si1863955oth.14.2020.02.11.04.49.42; Tue, 11 Feb 2020 04:49:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fqZNEJG0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728228AbgBKMrB (ORCPT + 99 others); Tue, 11 Feb 2020 07:47:01 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:57040 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728023AbgBKMrB (ORCPT ); Tue, 11 Feb 2020 07:47:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581425220; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/aoK1QXCzMorlswoGVCOoMeDkLwKz3AeoTqS+YSOfSw=; b=fqZNEJG0yTotnJQV9KTWjyUGl6PyU2DY8qc2Bv2qZjDn2CkS1rS46Mg+wyf8BH89+WwuR7 rhpcwp0TbbOSiQr34Mg9Q8sDyUpC7kxzbjy72lnRXJjahL/hBDzW/5Ore45lUs24kx8rrb f+ZV0bmxm97u8+BqVuEXxvaOc6l79Mg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-214-SXnDScXhMiOTsLtNUoNaXQ-1; Tue, 11 Feb 2020 07:46:56 -0500 X-MC-Unique: SXnDScXhMiOTsLtNUoNaXQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D097C477; Tue, 11 Feb 2020 12:46:54 +0000 (UTC) Received: from localhost (ovpn-12-50.pek2.redhat.com [10.72.12.50]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2754B5D9E2; Tue, 11 Feb 2020 12:46:51 +0000 (UTC) Date: Tue, 11 Feb 2020 20:46:48 +0800 From: Baoquan He To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, dan.j.williams@intel.com, richardw.yang@linux.intel.com Subject: Re: [PATCH 1/7] mm/sparse.c: Introduce new function fill_subsection_map() Message-ID: <20200211124648.GF8965@MiWiFi-R3L-srv> References: <20200209104826.3385-1-bhe@redhat.com> <20200209104826.3385-2-bhe@redhat.com> <0463a54b-12cb-667e-7c86-66cd707cec84@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0463a54b-12cb-667e-7c86-66cd707cec84@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/10/20 at 10:49am, David Hildenbrand wrote: > On 09.02.20 11:48, Baoquan He wrote: > > Wrap the codes filling subsection map in section_activate() into > > fill_subsection_map(), this makes section_activate() cleaner and > > easier to follow. > > > > Signed-off-by: Baoquan He > > --- > > mm/sparse.c | 45 ++++++++++++++++++++++++++++++++++----------- > > 1 file changed, 34 insertions(+), 11 deletions(-) > > > > diff --git a/mm/sparse.c b/mm/sparse.c > > index c184b69460b7..9ad741ccbeb6 100644 > > --- a/mm/sparse.c > > +++ b/mm/sparse.c > > @@ -788,24 +788,28 @@ static void section_deactivate(unsigned long pfn, unsigned long nr_pages, > > depopulate_section_memmap(pfn, nr_pages, altmap); > > } > > > > -static struct page * __meminit section_activate(int nid, unsigned long pfn, > > - unsigned long nr_pages, struct vmem_altmap *altmap) > > +/** > > + * fill_subsection_map - fill subsection map of a memory region > > + * @pfn - start pfn of the memory range > > + * @nr_pages - number of pfns to add in the region > > + * > > + * This clears the related subsection map inside one section, and only > > + * intended for hotplug. > > + * > > + * Return: > > + * * 0 - On success. > > + * * -EINVAL - Invalid memory region. > > + * * -EEXIST - Subsection map has been set. > > + */ > > +static int fill_subsection_map(unsigned long pfn, unsigned long nr_pages) > > { > > - DECLARE_BITMAP(map, SUBSECTIONS_PER_SECTION) = { 0 }; > > struct mem_section *ms = __pfn_to_section(pfn); > > - struct mem_section_usage *usage = NULL; > > + DECLARE_BITMAP(map, SUBSECTIONS_PER_SECTION) = { 0 }; > > unsigned long *subsection_map; > > - struct page *memmap; > > int rc = 0; > > > > subsection_mask_set(map, pfn, nr_pages); > > > > - if (!ms->usage) { > > - usage = kzalloc(mem_section_usage_size(), GFP_KERNEL); > > - if (!usage) > > - return ERR_PTR(-ENOMEM); > > - ms->usage = usage; > > - } > > subsection_map = &ms->usage->subsection_map[0]; > > > > if (bitmap_empty(map, SUBSECTIONS_PER_SECTION)) > > @@ -816,6 +820,25 @@ static struct page * __meminit section_activate(int nid, unsigned long pfn, > > bitmap_or(subsection_map, map, subsection_map, > > SUBSECTIONS_PER_SECTION); > > > > + return rc; > > +} > > + > > +static struct page * __meminit section_activate(int nid, unsigned long pfn, > > + unsigned long nr_pages, struct vmem_altmap *altmap) > > +{ > > + struct mem_section *ms = __pfn_to_section(pfn); > > + struct mem_section_usage *usage = NULL; > > + struct page *memmap; > > + int rc = 0; > > + > > + if (!ms->usage) { > > + usage = kzalloc(mem_section_usage_size(), GFP_KERNEL); > > + if (!usage) > > + return ERR_PTR(-ENOMEM); > > + ms->usage = usage; > > + } > > + > > + rc = fill_subsection_map(pfn, nr_pages); > > if (rc) { > > if (usage) > > ms->usage = NULL; > > > > What about having two variants of > section_activate()/section_deactivate() instead? Then we don't have any > subsection related stuff in !subsection code. Thanks for looking into this, David. Having two variants of section_activate()/section_deactivate() is also good. Just not like memmap handling which is very different between classic sparse and vmemmap, makes having two variants very attractive, the code and logic in section_activate()/section_deactivate() is not too much, and both of them basically can share the most of code, these make the variants way not so necessary. I personally prefer the current way, what do you think? Thanks Baoquan