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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2BB95C433F5 for ; Mon, 18 Oct 2021 14:06:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AB25460EFE for ; Mon, 18 Oct 2021 14:06:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AB25460EFE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 0CF126B006C; Mon, 18 Oct 2021 10:06:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 07F106B0071; Mon, 18 Oct 2021 10:06:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAFF2900002; Mon, 18 Oct 2021 10:06:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0178.hostedemail.com [216.40.44.178]) by kanga.kvack.org (Postfix) with ESMTP id D99C46B006C for ; Mon, 18 Oct 2021 10:06:28 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 9917F1838E510 for ; Mon, 18 Oct 2021 14:06:28 +0000 (UTC) X-FDA: 78709733256.16.F9349BD Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf12.hostedemail.com (Postfix) with ESMTP id 39077100009D for ; Mon, 18 Oct 2021 14:06:28 +0000 (UTC) Received: by mail-ed1-f51.google.com with SMTP id z20so71784472edc.13 for ; Mon, 18 Oct 2021 07:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6UixV+EdomTwPpwLU4H+5Kh+2/hbrZPIG6cjBtiBusg=; b=MCIAtXvnQI30oJmdNR5cBsekek9W/8uNYyD6fDf8QxTZvvO4Fw3ov1ryDrmA4eoomj qHOF+qkymVv4YWNCUzfCFRr0f5BaUUyyzHAZmQ8RIwcwjjcjO7+bukagjlYJ76XaseAv RomhBIaD8VPkqkqT6wz4p40FZzHfpvr3XWlmHewEmkcS+FqNuva/7g+LiseCCs5ulhUH TQNVST1/keSQx+vldfGG//VJ2y1vFnFimWcf3B68wwdloiVZmKWx1NEu9EWDQIrE1VlH 9VQFiNuFXiwvVGuTy+7lLteAjdnxgfC3xvQ+9SS2NmOJj36kKiULMfzucyCd5V/I3UyT nFgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6UixV+EdomTwPpwLU4H+5Kh+2/hbrZPIG6cjBtiBusg=; b=WiwXev+RARw3eqwxCPK8FcJIUHafvTRdzkxoESsNBMMZbOf+Dl3utBAU1S/RQH2cLo n1ey8rYMGePas+97Z1q2/xR6fWyf4aUe9OtR23qW8hyqeRgWQtyseWqX3tu0Xv3cvlr9 0i4TX+vKKBXx0cfYpMN1dzwnMF84lAX5DIqmemXcLtZvP2++XRuE304gicFkvmZFCPGD 2MH1wuLpMQUsotu3qACXwRSDw3J0sXtSKk3TCHEmIxjDVgcg45Z47IJwd29ZsKED0bKK AFqkYe6KfoclYjr1M+NgCqePySfbeVIyMnkJ1Z7GFiFWMX1m7JpRc77uchnApk/eqJzk 6JtA== X-Gm-Message-State: AOAM533kJBUmtw3Id1cyPW2muu8ZDjJ0DG5w29MMyncJVxtvPd2SV5sq 56Uh0O+meVLXkordoFx6O/oSY6O97NCkVlWepSA= X-Google-Smtp-Source: ABdhPJw/egDfBK7OLVjazvmdGX0qYDDzi//DgLoi75pycs6jKdhHN9O2O86JjGmU9mywoXPLjqMSyLsu5trSDQhFwZI= X-Received: by 2002:a05:6402:22d6:: with SMTP id dm22mr45281085edb.209.1634565793970; Mon, 18 Oct 2021 07:03:13 -0700 (PDT) MIME-Version: 1.0 References: <20211018123710.1540996-1-chenwandun@huawei.com> <20211018123710.1540996-2-chenwandun@huawei.com> In-Reply-To: <20211018123710.1540996-2-chenwandun@huawei.com> From: Uladzislau Rezki Date: Mon, 18 Oct 2021 16:03:02 +0200 Message-ID: Subject: Re: [PATCH v2 1/2] mm/vmalloc: fix numa spreading for large hash tables To: Chen Wandun Cc: Andrew Morton , Nicholas Piggin , Linux Memory Management List , LKML , Eric Dumazet , Kefeng Wang , guohanjun@huawei.com, Shakeel Butt Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 39077100009D X-Stat-Signature: fukweyphewoi1o6ggoyqsrph5gqjiu6r Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=MCIAtXvn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=urezki@gmail.com X-HE-Tag: 1634565988-52968 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > Eric Dumazet reported a strange numa spreading info in [1], and found > commit 121e6f3258fe ("mm/vmalloc: hugepage vmalloc mappings") introduced > this issue [2]. > > Dig into the difference before and after this patch, page allocation has > some difference: > > before: > alloc_large_system_hash > __vmalloc > __vmalloc_node(..., NUMA_NO_NODE, ...) > __vmalloc_node_range > __vmalloc_area_node > alloc_page /* because NUMA_NO_NODE, so choose alloc_page branch */ > alloc_pages_current > alloc_page_interleave /* can be proved by print policy mode */ > > after: > alloc_large_system_hash > __vmalloc > __vmalloc_node(..., NUMA_NO_NODE, ...) > __vmalloc_node_range > __vmalloc_area_node > alloc_pages_node /* choose nid by nuam_mem_id() */ > __alloc_pages_node(nid, ....) > > So after commit 121e6f3258fe ("mm/vmalloc: hugepage vmalloc mappings"), > it will allocate memory in current node instead of interleaving allocate > memory. > > [1] > https://lore.kernel.org/linux-mm/CANn89iL6AAyWhfxdHO+jaT075iOa3XcYn9k6JJc7JR2XYn6k_Q@mail.gmail.com/ > > [2] > https://lore.kernel.org/linux-mm/CANn89iLofTR=AK-QOZY87RdUZENCZUT4O6a0hvhu3_EwRMerOg@mail.gmail.com/ > > Fixes: 121e6f3258fe ("mm/vmalloc: hugepage vmalloc mappings") > Reported-by: Eric Dumazet > Signed-off-by: Chen Wandun > --- > mm/vmalloc.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index d77830ff604c..87552a4018aa 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2816,6 +2816,8 @@ vm_area_alloc_pages(gfp_t gfp, int nid, > unsigned int order, unsigned int nr_pages, struct page **pages) > { > unsigned int nr_allocated = 0; > + struct page *page; > + int i; > > /* > * For order-0 pages we make use of bulk allocator, if > @@ -2823,7 +2825,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid, > * to fails, fallback to a single page allocator that is > * more permissive. > */ > - if (!order) { > + if (!order && nid != NUMA_NO_NODE) { > while (nr_allocated < nr_pages) { > unsigned int nr, nr_pages_request; > > @@ -2848,7 +2850,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid, > if (nr != nr_pages_request) > break; > } > - } else > + } else if (order) > /* > * Compound pages required for remap_vmalloc_page if > * high-order pages. > @@ -2856,11 +2858,13 @@ vm_area_alloc_pages(gfp_t gfp, int nid, > gfp |= __GFP_COMP; > > /* High-order pages or fallback path if "bulk" fails. */ > - while (nr_allocated < nr_pages) { > - struct page *page; > - int i; > > - page = alloc_pages_node(nid, gfp, order); > + page = NULL; > Why do you need to set page to NULL here? -- Vlad Rezki