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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8DD73CA0EC3 for ; Tue, 12 Sep 2023 13:21:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 110D86B00EA; Tue, 12 Sep 2023 09:21:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C1196B00EB; Tue, 12 Sep 2023 09:21:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF1A96B00EC; Tue, 12 Sep 2023 09:21:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id DCBCD6B00EA for ; Tue, 12 Sep 2023 09:21:58 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B0A891203F2 for ; Tue, 12 Sep 2023 13:21:58 +0000 (UTC) X-FDA: 81228008316.04.B56C1BA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf21.hostedemail.com (Postfix) with ESMTP id C616E1C0004 for ; Tue, 12 Sep 2023 13:21:56 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=KCc2qbtl; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf21.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694524916; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZD6YWQJqPrWvbOfZQJq7iTJokWiyIC+lAqfbjqQ8NIw=; b=ONKhjbl4RFCY/wyvFqf4K6KHa1y9EiSVqsZMjPJZmWwFk4IOox6Y01PpvkwdpX7IqBK4P1 TT8oBGNY/fIJt09vC5rnomW7Xsm36UjZ5QELCrgQlxNVpVwpEAMTSrMElmtndIQaBORrfh uLFxoith9vBkP83uZ9SvJp5EMu7TzPc= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=KCc2qbtl; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf21.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694524916; a=rsa-sha256; cv=none; b=27IqfteYUi1mz8H4RofO6UmqDhTeYulm8q1pOfMY7JFS4XW1hs5R8HGlKj3yJ4wycPARCS EtqNUo+jYAbHEQDBcTTB3enJA9hWuljcVx/sphCDd972afSWCjf8jC4TEbjx4Ky1SNTMWo omcJZW9nwEiNWrs0TWYJN60cQfvD+/g= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694524916; 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: in-reply-to:in-reply-to:references:references; bh=ZD6YWQJqPrWvbOfZQJq7iTJokWiyIC+lAqfbjqQ8NIw=; b=KCc2qbtlJ/xlPGs1VzxV+MTP1xm5AsmnWgVn93RsWMEDqfjYk/153CsX6BjPUWCIleJePv iFEZnyLE3OgJhZXR8TTNOS1h+Sh5W1Cn/vkgv0tOsRuUvcEaxZGe5RZAg+Y2Gwg3W37uOg eLtvlh8R5lGII/M9+kqLA1Aql1zARXo= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-182-wNPhRgZgPde1KIJoDFaalw-1; Tue, 12 Sep 2023 09:21:52 -0400 X-MC-Unique: wNPhRgZgPde1KIJoDFaalw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 253638FBCE3; Tue, 12 Sep 2023 13:21:52 +0000 (UTC) Received: from localhost (unknown [10.72.112.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7150D40C6EBF; Tue, 12 Sep 2023 13:21:51 +0000 (UTC) Date: Tue, 12 Sep 2023 21:21:47 +0800 From: Baoquan He To: Uladzislau Rezki Cc: linux-mm@kvack.org, Andrew Morton , LKML , Lorenzo Stoakes , Christoph Hellwig , Matthew Wilcox , "Liam R . Howlett" , Dave Chinner , "Paul E . McKenney" , Joel Fernandes , Oleksiy Avramchenko Subject: Re: [PATCH v2 6/9] mm: vmalloc: Offload free_vmap_area_lock lock Message-ID: References: <20230829081142.3619-1-urezki@gmail.com> <20230829081142.3619-7-urezki@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: C616E1C0004 X-Stat-Signature: h1i5cnduztme97e8gdmiz1k8jsfizdik X-Rspam-User: X-HE-Tag: 1694524916-529055 X-HE-Meta: U2FsdGVkX1+BpCKQiQHJeGOnqTQSGoX1SFKRspLESKgXjWd3sRCL3mE856Hfqtl5gamMIWaB8RJEP0+4ZjzVEo1jlPJ8ZnYOf2sdpliw6uMNLngrv4HWryuc6FmNgsUQWD04rxGDGmGlrDnGU188+D4tbjuA4bBBPn9XApkHJgQIdVuEgdB8tzSJHYBTRZW4SVgl6gURc4n46h7mck0la2MJ7TvH76Di9a3pZ4iAQhhT3hMmQetOlyEVwHFfRTzzDEAzYQK6cua8mWwqtJYxqMnY8pmaX0CQHhR4F7en5gUNpo8EzY41kJEAqqXMWKr3QQm3UNlk3qq9IrN/0gdcUOUMSKtOMrYbwCld8+NTyUbhNKNlWvZ3WEYxGII87WJ3JBSs69FH5aQrcK430e+XlfmVRS9e/7oqNHF6Q5h9w3/F0Lzco7cnqOQM6oZ7HqnAjBHmjtxxlixmMOQt3cpn7CXhnyGUbMk7gpq0K5GGCVN83WeRoHt2NL620G6XLYU1O8dbuioUJx6U3AdRUF2JoP7aPGh8eHQ7K/7OwFOZ+l5WIWLmM9uzXB4+i97aCtzv83we2NaC4njHeDPSVJ6olplrkQ/1WDswU/AQbB/LF65rGh9Mu22zCMLZblc9RBhPRIwBo817VwR06V6AIRQMlR11H1Hd3dqyMWyztv9CEJQOg3UQH7E743z419W7h8hk/kKr34fZFoLjzJUOwIDpnzTGo0c6mI2tE7yniBW9EYHgvRQwpPVuXJm7XQehnTRzv9R+DrfyKZnLK/DGPpmz+xAb8ysyuRtewVZB4H2SIak0TmJmzUtF1lQ3WpznV5oQCTb4/jtHHcR70rapo+mT/tiUutZ7TMpvfpCvnLJVoCn/N5ULZFg1rmICPn/owiogtyrE3RHU0tDDvV02HgOB9+vWcFUmm5Ks5AYlQmoVLoW2FWcuZWzCALrMhJuPEw+YMWwYBOU5+FDBpJ8lvms NiedBpk0 mublpP58Q5CK/w5Iewh997My4wMoIuDBEPgiTZ9LbAsBpzbcDey/C7JzvWcMnO8OqVEPymBTVay4iO1NzjPgVvLIRm6xx+NWECPRDQFeyC0plrI8KCzmkhklWiQIPX8G5xTAo0VYstcaLcjz+a2RDmp0SfpetBhEmP+sxvwly5GjiTtaFnngvTRNvO7od1OmwXvjrvViTR48TBkaKoW9oY5kn9PF/tETk/Y9vzQXZMmhFVJ62oXkTtxGbIXJ0ktc9IjTWGsrMErt3redhoAs0Un3iIA== 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 09/11/23 at 07:10pm, Uladzislau Rezki wrote: > On Mon, Sep 11, 2023 at 11:25:01AM +0800, Baoquan He wrote: > > On 08/29/23 at 10:11am, Uladzislau Rezki (Sony) wrote: > > > Concurrent access to a global vmap space is a bottle-neck. > > > We can simulate a high contention by running a vmalloc test > > > suite. > > > > > > To address it, introduce an effective vmap node logic. Each > > > node behaves as independent entity. When a node is accessed > > > it serves a request directly(if possible) also it can fetch > > > a new block from a global heap to its internals if no space > > > or low capacity is left. > > > > > > This technique reduces a pressure on the global vmap lock. > > > > > > Signed-off-by: Uladzislau Rezki (Sony) > > > --- > > > mm/vmalloc.c | 316 +++++++++++++++++++++++++++++++++++++++++++++------ > > > 1 file changed, 279 insertions(+), 37 deletions(-) > > > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > > index 5a8a9c1370b6..4fd4915c532d 100644 > > > --- a/mm/vmalloc.c > > > +++ b/mm/vmalloc.c > > > @@ -779,6 +779,7 @@ struct rb_list { > > > > > > struct vmap_node { > > > /* Bookkeeping data of this node. */ > > > + struct rb_list free; > > > struct rb_list busy; > > > struct rb_list lazy; > > > > > > @@ -786,6 +787,13 @@ struct vmap_node { > > > * Ready-to-free areas. > > > */ > > > struct list_head purge_list; > > > + struct work_struct purge_work; > > > + unsigned long nr_purged; > > > + > > > + /* > > > + * Control that only one user can pre-fetch this node. > > > + */ > > > + atomic_t fill_in_progress; > > > }; > > > > > > static struct vmap_node *nodes, snode; > > > @@ -804,6 +812,32 @@ addr_to_node(unsigned long addr) > > > return &nodes[addr_to_node_id(addr)]; > > > } > > > > > > +static inline struct vmap_node * > > > +id_to_node(int id) > > > +{ > > > + return &nodes[id % nr_nodes]; > > > +} > > > + > > > +static inline int > > > +this_node_id(void) > > > +{ > > > + return raw_smp_processor_id() % nr_nodes; > > > +} > > > + > > > +static inline unsigned long > > > +encode_vn_id(int node_id) > > > +{ > > > + /* Can store U8_MAX [0:254] nodes. */ > > > + return (node_id + 1) << BITS_PER_BYTE; > > > +} > > > + > > > +static inline int > > > +decode_vn_id(unsigned long val) > > > +{ > > > + /* Can store U8_MAX [0:254] nodes. */ > > > + return (val >> BITS_PER_BYTE) - 1; > > > +} > > > > This patch looks good to me. However, should we split out the encoding > > vn_id into va->flags optimization into another patch? It looks like an > > independent optimization which can be described better with specific > > log. At least, in the pdf file pasted or patch log, it's not obvious > > that: > > 1) node's free tree could contains any address range; > > 2) nodes' busy tree only contains address range belonging to this node; > > - could contain crossing node range, corner case. > > 3) nodes' purge tree could contain any address range; > > - decided by encoded vn_id in va->flags. > > - decided by address via addr_to_node(va->va_start). > > > > Personal opinion, feel it will make reviewing easier. > > > Sure, if it is easier to review, then i will split these two parts. > All three statements are correct and valid. The pdf file only covers > v1, so it is not up to date. > > Anyway i will update a cover letter in v3 with more details. Maybe providing these details in patch log or cover letter is enough. Leave it to you to decide if splitting patch is still needed. Thanks.