Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp5952341ybv; Wed, 12 Feb 2020 03:22:11 -0800 (PST) X-Google-Smtp-Source: APXvYqzIlQZNTpwPA9lLxxcLuEma9ioIcKFdCwseesWkCCmx+/KTjmyCqxe2FAa9MzZpfMsJz0id X-Received: by 2002:aca:bc0a:: with SMTP id m10mr5952469oif.77.1581506531119; Wed, 12 Feb 2020 03:22:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581506531; cv=none; d=google.com; s=arc-20160816; b=LGca1jKr8IR0GzmBZxFUbrMBplostI7UI0xLkIJURC/UAaKZPu3xygFiGwjeaZXTRF Ek4m3oxHeHj3OMcZiORIVjmTU9okxL7PEmMvYvKN6tQna5ocdmjrhNHP5g9xKSp/RHWm 2GD2dwalHGQ9Xkj7yPkinli37Ay9WJfOA6d1derdR02qVJXlAitRFovTRp8OmMGsi18Z IGT/IIfHIkn/edvc4M1Zn5nn07JeJDaDtaRd+T13mobiH7ioYusyKu7bqezJTTMUD22s MhRxMZq4CpBfNq2BjliJxLwBcEkfk7gEyD0t0KYqHSViKR3qjnbJwkG8LrywqfOYM0G3 nvbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:user-agent :in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:dkim-signature; bh=ISQpWX8qRdL9ZLUrbjv3TLSIeU6toSMj/m/1mOebzDg=; b=eFUoHymxSrPu3EXCiXJPG9/K7CWwi1/P4GVCPdeRtv7T3HJ0vzSkX+W59O3zemdR9s AE8OMZQm16Nc6KzVa4vq/ZiyhmtA9xv3Wr7+XkpVpklSXnFl5anG3qKWpljFOzoBwo6A 9F6nKZNv3sw4TpS0Lm0UD0qrDDA5WrOVKxcAb47LKNbM4XPhQgKtKSKzOS3IhfEeSQR1 TebGk/iM/oADJU4LT9jQPZY4jDbhhbzD5CEmIk2u/GXa/xiyf0eQNQsCsLisL2+IYYgF qKXYwYU8xYY78o4+BkGkurHlBltRmKz2ZymJPXvmc0yhVsJE1Nfgj+KK0jWAcZjYYbPR pIFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SKwd+Yaa; 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 m19si72029otr.18.2020.02.12.03.21.48; Wed, 12 Feb 2020 03:22:11 -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=SKwd+Yaa; 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 S1728048AbgBLLUP (ORCPT + 99 others); Wed, 12 Feb 2020 06:20:15 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:28183 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727947AbgBLLUO (ORCPT ); Wed, 12 Feb 2020 06:20:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581506413; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ISQpWX8qRdL9ZLUrbjv3TLSIeU6toSMj/m/1mOebzDg=; b=SKwd+YaabkzXD1FiGR8WCJmU3mjytecEhUlsoxQGoxBT1fJfh0Z/jfZkzVeCVuAWBvFoPo toA1vRgfgAhSGd/zE6cN5qQDTIJbNshQjpXJViM/t7QQygbLxhLIgW7XT13yMf2I9ZzLHN TKqgqXlBnl1G98wlZCigjyly41qkntw= 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-175-XcEi_Dj7MAiCndTsDJgohg-1; Wed, 12 Feb 2020 06:20:11 -0500 X-MC-Unique: XcEi_Dj7MAiCndTsDJgohg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4313BDB65; Wed, 12 Feb 2020 11:20:10 +0000 (UTC) Received: from localhost (ovpn-12-47.pek2.redhat.com [10.72.12.47]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D719E1001B07; Wed, 12 Feb 2020 11:20:03 +0000 (UTC) Date: Wed, 12 Feb 2020 19:20:00 +0800 From: Baoquan He To: Dan Williams , David Hildenbrand Cc: Linux Kernel Mailing List , Linux MM , Andrew Morton , Wei Yang Subject: Re: [PATCH 3/7] mm/sparse.c: only use subsection map in VMEMMAP case Message-ID: <20200212112000.GH8965@MiWiFi-R3L-srv> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/12/20 at 10:39am, David Hildenbrand wrote: >=20 >=20 > > Am 11.02.2020 um 21:15 schrieb Dan Williams : > >=20 > > =EF=BB=BFOn Sun, Feb 9, 2020 at 2:48 AM Baoquan He w= rote: > >>=20 > >> Currently, subsection map is used when SPARSEMEM is enabled, includi= ng > >> VMEMMAP case and !VMEMMAP case. However, subsection hotplug is not > >> supported at all in SPARSEMEM|!VMEMMAP case, subsection map is unnec= essary > >> and misleading. Let's adjust code to only allow subsection map being > >> used in SPARSEMEM|VMEMMAP case. > >>=20 > >> Signed-off-by: Baoquan He > >> --- > >> include/linux/mmzone.h | 2 + > >> mm/sparse.c | 231 ++++++++++++++++++++++-----------------= -- > >> 2 files changed, 124 insertions(+), 109 deletions(-) > >>=20 > >> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > >> index 462f6873905a..fc0de3a9a51e 100644 > >> --- a/include/linux/mmzone.h > >> +++ b/include/linux/mmzone.h > >> @@ -1185,7 +1185,9 @@ static inline unsigned long section_nr_to_pfn(= unsigned long sec) > >> #define SUBSECTION_ALIGN_DOWN(pfn) ((pfn) & PAGE_SUBSECTION_MASK) > >>=20 > >> struct mem_section_usage { > >> +#ifdef CONFIG_SPARSEMEM_VMEMMAP > >> DECLARE_BITMAP(subsection_map, SUBSECTIONS_PER_SECTION); > >> +#endif > >=20 > > This was done deliberately so that the SPARSEMEM_VMEMMAP=3Dn case ran= as > > a subset of the SPARSEMEM_VMEMMAP=3Dy case. Thanks for checking this, Dan. Taking away the subsection part, won't affect the classic sparse being a subset of VMEMMAP case, I would say. > >=20 > > The diffstat does not seem to agree that this is any clearer: > >=20 > > 124 insertions(+), 109 deletions(-) > >=20 >=20 > I don=E2=80=98t see a reason to work with subsections (+store them) if = subsections are not supported. >=20 > I do welcome this cleanup. Diffstats don=E2=80=98t tell the whole story= . Thanks for clarifying this, David, I agree. If applying the patch, it should be easier to observe that the code is simpler to follow, at least won't be confusing on subsection handling part.