From: Uladzislau Rezki <urezki@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Uladzislau Rezki <urezki@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
peter enderborg <peter.enderborg@sony.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
GregKroah-Hartmangregkh@linuxfoundation.org,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: nr_cpu_ids vs AMD 3970x(32 physical CPUs)
Date: Sat, 4 Jul 2020 00:22:26 +0200 [thread overview]
Message-ID: <20200703222226.GA7472@pc636> (raw)
In-Reply-To: <20200703215157.GI25523@casper.infradead.org>
On Fri, Jul 03, 2020 at 10:51:57PM +0100, Matthew Wilcox wrote:
> On Fri, Jul 03, 2020 at 11:20:47PM +0200, Uladzislau Rezki wrote:
> > Some background:
> > Actually i have been thinking about making vmalloc address space to
> > be per-CPU, i.e. divide it to per-CPU address space making an allocation
> > lock-less. It will eliminate a high lock contention. When i have done
> > a prototype i noticed and realized that there is a silly issue with
> > nr_cpu_ids on some systems.
>
> vfree() may happen on a different CPU from the one which called vmalloc(),
> so I'm not sure you're going to get as large a win as you think you will.
>
Hmm.. According to my tests the difference is approximately 7x/10x but
i also need to say as of now those tests are draft. Indeed vfree() can
be done on different CPU, but i do not think it is a big issue. The main
goal is to make the vmalloc() to be scaled to number of CPUs in a system.
Because as number of CPUs increase as tight an allocation becomes.
Doing vfree() on another CPU would be kind of noise(critical section is
short), whereas other ones will be able to do progress because of their
own locks.
--
Vlad Rezki
prev parent reply other threads:[~2020-07-03 22:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-03 15:57 nr_cpu_ids vs AMD 3970x(32 physical CPUs) Uladzislau Rezki
2020-07-03 16:56 ` Peter Zijlstra
2020-07-03 17:09 ` Uladzislau Rezki
2020-07-03 17:38 ` Peter Zijlstra
2020-07-03 19:26 ` Uladzislau Rezki
2020-07-03 17:07 ` Gabriel C
2020-07-03 17:24 ` Uladzislau Rezki
2020-07-03 17:45 ` Peter Zijlstra
2020-07-03 18:36 ` Gabriel C
2020-07-03 19:05 ` peter enderborg
2020-07-03 19:28 ` Uladzislau Rezki
2020-07-03 20:08 ` Linus Torvalds
2020-07-03 21:20 ` Uladzislau Rezki
2020-07-03 21:51 ` Matthew Wilcox
2020-07-03 22:22 ` Uladzislau Rezki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200703222226.GA7472@pc636 \
--to=urezki@gmail.com \
--cc=GregKroah-Hartmangregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peter.enderborg@sony.com \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).