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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham 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 C9C7BC6778A for ; Mon, 2 Jul 2018 02:31:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8138025774 for ; Mon, 2 Jul 2018 02:31:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8138025774 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932975AbeGBCbh (ORCPT ); Sun, 1 Jul 2018 22:31:37 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:34430 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932722AbeGBCbf (ORCPT ); Sun, 1 Jul 2018 22:31:35 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5FD057D84D; Mon, 2 Jul 2018 02:31:34 +0000 (UTC) Received: from localhost (ovpn-8-16.pek2.redhat.com [10.72.8.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 175CB2156880; Mon, 2 Jul 2018 02:31:32 +0000 (UTC) Date: Mon, 2 Jul 2018 10:31:30 +0800 From: Baoquan He To: Pavel Tatashin Cc: Steven Sistare , Daniel Jordan , LKML , Andrew Morton , kirill.shutemov@linux.intel.com, Michal Hocko , Linux Memory Management List , dan.j.williams@intel.com, jack@suse.cz, jglisse@redhat.com, Souptick Joarder , gregkh@linuxfoundation.org, Vlastimil Babka , Wei Yang , dave.hansen@intel.com, rientjes@google.com, mingo@kernel.org, osalvador@techadventures.net Subject: Re: [PATCH v3 1/2] mm/sparse: add sparse_init_nid() Message-ID: <20180702023130.GM3223@MiWiFi-R3L-srv> References: <20180702020417.21281-1-pasha.tatashin@oracle.com> <20180702020417.21281-2-pasha.tatashin@oracle.com> <20180702021121.GL3223@MiWiFi-R3L-srv> 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.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 02 Jul 2018 02:31:34 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 02 Jul 2018 02:31:34 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.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 07/01/18 at 10:18pm, Pavel Tatashin wrote: > > Here, I think it might be not right to jump to 'failed' directly if one > > section of the node failed to populate memmap. I think the original code > > is only skipping the section which memmap failed to populate by marking > > it as not present with "ms->section_mem_map = 0". > > > > Hi Baoquan, > > Thank you for a careful review. This is an intended change compared to > the original code. Because we operate per-node now, if we fail to > allocate a single section, in this node, it means we also will fail to > allocate all the consequent sections in the same node and no need to > check them anymore. In the original code we could not simply bailout, > because we still might have valid entries in the following nodes. > Similarly, sparse_init() will call sparse_init_nid() for the next node > even if previous node failed to setup all the memory. Hmm, say the node we are handling is node5, and there are 100 sections. If you allocate memmap for section at one time, you have succeeded to handle for the first 99 sections, now the 100th failed, so you will mark all sections on node5 as not present. And the allocation failure is only for single section memmap allocation case. Please think about the vmemmap case, it will map the struct page pages to vmemmap, and will populate page tables for them to map. That is a long walk, not only memmory allocation, and page table checking and populating, one section failing to populate memmap doesn't mean all the consequent sections also failed. I think the original code is reasonable. Thanks Baoquan