From: Christopher Lameter <cl@linux.com>
To: Pekka Enberg <penberg@gmail.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Xunlei Pang <xlpang@linux.alibaba.com>,
Andrew Morton <akpm@linux-foundation.org>,
Wen Yang <wenyang@linux.alibaba.com>,
Yang Shi <yang.shi@linux.alibaba.com>,
Roman Gushchin <guro@fb.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 1/2] mm/slub: Introduce two counters for the partial objects
Date: Fri, 7 Aug 2020 13:02:43 +0000 (UTC) [thread overview]
Message-ID: <alpine.DEB.2.22.394.2008071258020.55871@www.lameter.com> (raw)
In-Reply-To: <CAOJsxLHX62P0yvHZcXdje41zm_2demzTraqvHXAvfhVPp2HKsA@mail.gmail.com>
On Fri, 7 Aug 2020, Pekka Enberg wrote:
> I think we can just default to the counters. After all, if I
> understood correctly, we're talking about up to 100 ms time period
> with IRQs disabled when count_partial() is called. As this is
> triggerable from user space, that's a performance bug whatever way you
> look at it.
Well yes under extreme conditions and this is only happening for sysfs
counter retrieval.
There could be other solutions to this. This solution here is penalizing
evertu hotpath slab allocation for the sake of relatively infrequently
used counter monitoring. There the possibility of not traversing the list
ande simply estimating the value based on the number of slab pages
allocated on that node.
> Christoph, others, any objections?
Obviously .... ;-)
next prev parent reply other threads:[~2020-08-07 13:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-02 8:32 Xunlei Pang
2020-07-02 8:32 ` [PATCH 2/2] mm/slub: Get rid of count_partial() Xunlei Pang
2020-07-02 11:59 ` [PATCH 1/2] mm/slub: Introduce two counters for the partial objects Pekka Enberg
2020-07-03 9:37 ` xunlei
2020-07-07 15:23 ` Pekka Enberg
2020-07-09 14:32 ` Christopher Lameter
2020-07-31 2:57 ` xunlei
2020-07-07 6:59 ` Christopher Lameter
2020-07-31 2:52 ` xunlei
2020-08-06 12:42 ` Vlastimil Babka
2020-08-07 7:25 ` Pekka Enberg
2020-08-07 13:02 ` Christopher Lameter [this message]
2020-08-07 17:28 ` Pekka Enberg
2020-08-10 11:56 ` xunlei
2020-08-11 12:52 ` Christopher Lameter
2020-08-20 13:58 ` Pekka Enberg
2020-08-24 9:59 ` xunlei
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=alpine.DEB.2.22.394.2008071258020.55871@www.lameter.com \
--to=cl@linux.com \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=khlebnikov@yandex-team.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@gmail.com \
--cc=rientjes@google.com \
--cc=vbabka@suse.cz \
--cc=wenyang@linux.alibaba.com \
--cc=xlpang@linux.alibaba.com \
--cc=yang.shi@linux.alibaba.com \
/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