From: Christopher Lameter <cl@linux.com>
To: Pingfan Liu <kernelfans@gmail.com>
Cc: linux-mm@kvack.org, Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] mm/slub: disallow obj's allocation on page with mismatched pfmemalloc purpose
Date: Tue, 2 Oct 2018 14:47:39 +0000 [thread overview]
Message-ID: <01000166353fb3e2-2aa1bed8-26f1-4b9e-a48b-fbf0dd66b1d8-000000@email.amazonses.com> (raw)
In-Reply-To: <CAFgQCTtXQkiyr5GJuw1u8J0aW-B8ig_=PKyZCknktYB_rj4TEA@mail.gmail.com>
On Sun, 30 Sep 2018, Pingfan Liu wrote:
> > > In the debug case the slab needs to be deactivated. Otherwise the
> > > slowpath will not be used and debug checks on the following objects will
> > > not be done.
> > >
> After taking a more closely look at the debug code, I consider whether
> the alloc_debug_processing() can be also called after get_freelist(s,
> page), then deactivate_slab() is not required . My justification is
> the debug code will take the same code path as the non-debug, hence
> the page will experience the same transition on different list like
> the non-debug code, and help to detect the bug, also it will improve
> scalability on SMP.
> Besides this, I found the debug code is not scalable well, is it worth
> to work on it?
The debug code is kept out of the hot path intentionally because it does
not scale well and reduces performance. Its compiled in in case we have
to track down a nasty memory corruption bug on a prod kernel that cannot
be easily rebuilt.
prev parent reply other threads:[~2018-10-02 14:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-26 6:52 Pingfan Liu
2018-09-26 16:14 ` Christopher Lameter
2018-09-27 13:15 ` Pingfan Liu
2018-09-30 9:33 ` Pingfan Liu
2018-10-02 14:47 ` Christopher Lameter [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=01000166353fb3e2-2aa1bed8-26f1-4b9e-a48b-fbf0dd66b1d8-000000@email.amazonses.com \
--to=cl@linux.com \
--cc=akpm@linux-foundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=kernelfans@gmail.com \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.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