Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp7237703imm; Wed, 27 Jun 2018 23:43:19 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdgKINK7jOe2YGJOqwPNuHPXUzxq4cPoXEFQgqadpq2vRKo+PIjt9ZKzije9XdYTn8+PMs5 X-Received: by 2002:a17:902:5481:: with SMTP id e1-v6mr2650808pli.7.1530168199473; Wed, 27 Jun 2018 23:43:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530168199; cv=none; d=google.com; s=arc-20160816; b=qwW4bFueG7vZ1ZKMkamoDSUOSJncBmbzNyQR/nhv9CyqVu4UnwnLJRJwXvDeKef6cC dsEUS9wC6i3zMqsD6DFljEZjas4LAnfCRg/zq8E0xkr6q00Iv9EY0MmjNxZU8Yu5yyLa bHZq9Vd9r4FGj4paPG7IfGQMgWIy99SFq+L7EZr1nsOEQ7JnZv/FTY8ACweaJNfwQf1u +/hd4nngkIGo4AmElrRvyqnKjtz3UP8lZK38m1ejfK/6Y/90UGva9x4S8YT/Ka5C8WCx Tn7n1bjC0yYX4vlZo8b7+0GZRnbXXOTb8kURbVMyH7EN5XbE5arwEqqusqU8jV46ZBne zbRQ== 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:arc-authentication-results; bh=tp/ULqyZX1KUFJZqDfjX2jFkRAM03gUD6OMMUM0su8g=; b=T2Qcd/gBbdGb0Fn8JEsqdCZiqPXwt8+PrA/Drvkn6M8iD5WM+0df/mFSo23VqMappG mvFrQVIRmCFStJcfIbWhi6msHKAq4i7osVWpwcH8xsG81NNgAQ6yPofRb66BGhynzv35 OSr9zfZ4prnVFITB2EzJXg4fe5wykgAvC+ATGlXrATGTCGmMYwVApJxlC1HUPLv2HRG5 +TozvR6bjluzITmU5AATV+FMhqOM96FI+8a9CkQTefj1HOu+rPoW4b0d8+6UwTjfa/wI ZRxdHcK1O2MjdrNKmipnrJ3KPp/sdTHWcIg+niFtwOif4TofCtMoGv8uAnbOfdP3/S/K 6HrA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (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 y187-v6si943517pfy.101.2018.06.27.23.43.05; Wed, 27 Jun 2018 23:43:19 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753634AbeF1GjH (ORCPT + 99 others); Thu, 28 Jun 2018 02:39:07 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:36214 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751986AbeF1GjG (ORCPT ); Thu, 28 Jun 2018 02:39:06 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BA9528A3AB; Thu, 28 Jun 2018 06:39:05 +0000 (UTC) Received: from localhost (ovpn-8-16.pek2.redhat.com [10.72.8.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D211111166F1; Thu, 28 Jun 2018 06:39:04 +0000 (UTC) Date: Thu, 28 Jun 2018 14:39:01 +0800 From: Baoquan He To: Pavel Tatashin Cc: LKML , Andrew Morton , dave.hansen@intel.com, pagupta@redhat.com, Linux Memory Management List , kirill.shutemov@linux.intel.com Subject: Re: [PATCH v5 4/4] mm/sparse: Optimize memmap allocation during sparse_init() Message-ID: <20180628063901.GA32539@MiWiFi-R3L-srv> References: <20180627013116.12411-1-bhe@redhat.com> <20180627013116.12411-5-bhe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 28 Jun 2018 06:39:05 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 28 Jun 2018 06:39:05 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'bhe@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/27/18 at 11:19pm, Pavel Tatashin wrote: > > Signed-off-by: Baoquan He > > > > Signed-off-by: Baoquan He > > Please remove duplicated signed-off Done. > > > if (!usemap) { > > ms->section_mem_map = 0; > > + nr_consumed_maps++; > > Currently, we do not set ms->section_mem_map to 0 when fail to > allocate usemap, only when fail to allocate mmap we set > section_mem_map to 0. I think this is an existing bug. Yes, found it when changing code. Later in sparse_init(), added checking to see if usemap is available, otherwise also do "ms->section_mem_map = 0;" to clear its ->section_mem_map. Here if want to be perfect, we may need to free the relevant memmap because usemap is allocated together, memmap could be allocated one section by one section. I didn't do that because usemap allocation is smaller one, if that allocation even failed in this early system initializaiton stage, the kernel won't live long, so don't bother to do that to complicate code. > > Reviewed-by: Pavel Tatashin