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 32D78C433F5 for ; Wed, 13 Oct 2021 21:46:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D7532611C5 for ; Wed, 13 Oct 2021 21:46:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D7532611C5 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 43793940007; Wed, 13 Oct 2021 17:46:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3BEDA900002; Wed, 13 Oct 2021 17:46:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 286BA940007; Wed, 13 Oct 2021 17:46:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 17A75900002 for ; Wed, 13 Oct 2021 17:46:14 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C707518036FD8 for ; Wed, 13 Oct 2021 21:46:13 +0000 (UTC) X-FDA: 78692747826.34.DD3FAAB Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by imf04.hostedemail.com (Postfix) with ESMTP id 26D8C50000A8 for ; Wed, 13 Oct 2021 21:46:13 +0000 (UTC) Received: by mail-lf1-f45.google.com with SMTP id x27so17724328lfa.9 for ; Wed, 13 Oct 2021 14:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rUPiHKYI3IiGHt/c4QX+xoO8xtC6xojKkJlCXULl4So=; b=oAT8fjoxBlZc8GrTTmtA1uwkBPdy+udSVS2eT4Dy8Y4EZ9ys1gwAsfS1a90rPCHz7l c3bGuhJFzXZ9YrtwsQcHSmvFjQ5aY22W0l04mAwbWtv5wWpgRDwAkajRti9AdoeMULgi 6LcTe5nVpC5XaxUb59ZLTlMOC7X5LitH11Exs5NI7OOeGyxxCasLXeggEA/uT7YWQeNp yCFfyFi6BjRH8g2vIa/7r7oY0qefqTCNABotM1SFV429zk7bXpYoglX1CXaxZSODHHa4 hJs/DwEYxQG+DJO8Y0G70oN3P96WQgD4dMonc+lspAGUJucUhsf5+7+6DXwE/h+lY66i dWFw== 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=rUPiHKYI3IiGHt/c4QX+xoO8xtC6xojKkJlCXULl4So=; b=ZDz//0jYEFRdz4qB/8bebcqf2GcE3nO89kg/RogPNJ4EeaQZU91q3e1cZXtJCdaeEP RwXvfbFgokm/XkuVQSvDHeVYBW5pXvysoUZtpImUDDLzFpIpU0+SM6+55lzxHfNZwn1y aZHRB3lL9J3Mh3nv9YoMtOBQhiMk/uZtri9h3W40SKOeeuh8oL07L7sqxX+mYD2DVmTt C8sWwI6Isa/SPh1XLCWuUdUWAUVumPW0qkCz7l7PnJYJffAlZ5GUlwCuf1/SeJ1JJ7TO 4uuL9CMWvhRACtXUfCP2000G5aPjNVVn+U3jn2hXDDgp0i4WkWMoEQavap88re9ecgeQ ExEg== X-Gm-Message-State: AOAM532IOkx1uujlacaoE7TdKQ1KZusfkKzmlB0TB55cuB6Xb9qt1j4o R1KZj6Z3J90chBskcbHE8G4Ix/y39ObyrPx32NlYTw== X-Google-Smtp-Source: ABdhPJzYms6VDxNHTH25y6Ve9ZEiVkyoTDg2NOKHPGX4etB6OuHBPtqSDrppQ/lQsLO+qDJnBVmyTJSatPF1JNA1FcU= X-Received: by 2002:a05:6512:3b0a:: with SMTP id f10mr1512755lfv.8.1634161571450; Wed, 13 Oct 2021 14:46:11 -0700 (PDT) MIME-Version: 1.0 References: <20210928121040.2547407-1-chenwandun@huawei.com> In-Reply-To: <20210928121040.2547407-1-chenwandun@huawei.com> From: Shakeel Butt Date: Wed, 13 Oct 2021 14:46:00 -0700 Message-ID: Subject: Re: [PATCH] mm/vmalloc: fix numa spreading for large hash tables To: Chen Wandun Cc: Andrew Morton , Nicholas Piggin , Linux MM , LKML , Eric Dumazet , Kefeng Wang , guohanjun@huawei.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 26D8C50000A8 X-Stat-Signature: frwsi6nane9mttu4q7jcfqh75btw79m8 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=oAT8fjox; spf=pass (imf04.hostedemail.com: domain of shakeelb@google.com designates 209.85.167.45 as permitted sender) smtp.mailfrom=shakeelb@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1634161573-211031 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: On Tue, Sep 28, 2021 at 5:03 AM Chen Wandun wrote: > > 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 | 33 ++++++++++++++++++++++++++------- > 1 file changed, 26 insertions(+), 7 deletions(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index f884706c5280..48e717626e94 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -2823,6 +2823,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 > @@ -2833,6 +2835,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid, > if (!order) { Can you please replace the above with if (!order && nid != NUMA_NO_NODE)? > while (nr_allocated < nr_pages) { > unsigned int nr, nr_pages_request; > + page = NULL; > > /* > * A maximum allowed request is hard-coded and is 100 > @@ -2842,9 +2845,23 @@ vm_area_alloc_pages(gfp_t gfp, int nid, > */ > nr_pages_request = min(100U, nr_pages - nr_allocated); > Undo the following change in this if block. > - nr = alloc_pages_bulk_array_node(gfp, nid, > - nr_pages_request, pages + nr_allocated); > - > + if (nid == NUMA_NO_NODE) { > + for (i = 0; i < nr_pages_request; i++) { > + page = alloc_page(gfp); > + if (page) > + pages[nr_allocated + i] = page; > + else { > + nr = i; > + break; > + } > + } > + if (i >= nr_pages_request) > + nr = nr_pages_request; > + } else { > + nr = alloc_pages_bulk_array_node(gfp, nid, > + nr_pages_request, > + pages + nr_allocated); > + } > nr_allocated += nr; > cond_resched(); > > @@ -2863,11 +2880,13 @@ vm_area_alloc_pages(gfp_t gfp, int nid, Put the following line under "else if (order)" > gfp |= __GFP_COMP; > > /* High-order pages or fallback path if "bulk" fails. */ > - while (nr_allocated < nr_pages) { Keep the following declarations inside the while loop. > - struct page *page; > - int i; > > - page = alloc_pages_node(nid, gfp, order); > + page = NULL; > + while (nr_allocated < nr_pages) { > + if (nid == NUMA_NO_NODE) > + page = alloc_pages(gfp, order); > + else > + page = alloc_pages_node(nid, gfp, order); > if (unlikely(!page)) > break; > > -- > 2.25.1 >