From: Wonhyuk Yang <vvghjk1234@gmail.com>
To: Christoph Lameter <cl@gentwo.org>
Cc: linux-mm@kvack.org, Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [Question] The necessity of transaction ID in SLUB.
Date: Tue, 23 Nov 2021 21:18:28 +0900 [thread overview]
Message-ID: <CAEcHRTrTc-DzeyU4fetfyU3pQCS6A0pPexGe5c5yB94Z88ueHg@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2111231034140.13033@gentwo.de>
On Tue, Nov 23, 2021 at 6:38 PM Christoph Lameter <cl@gentwo.org> wrote:
>
> > Do you mean that without TID, multiple cpu can race on one
> > cpu_slab->freelist?
> >
> > How is it possible? As you know, cpu_slab is per-cpu variable and
> > cpu_slab->freelist is accessed via "this_cpu_cmpxchg" in the area
> > where preemption is enabled.
>
> That is the problem. Preemption is enabled. This means that slab_alloc can
> be preempted at any time and continue to run on an arbitrary other
> processor and also continue at an arbitrary time. It may also be
> rescheduled on the processor it ran before after executing just one
> instruction or so on another processor.
Yes, that's why transaction id is made up of two part CPU id and event id
(To guarantee there are no other events and migrations).
And the guarantee is ultimately to protect cpu_slab->freelist.
My point is, we can protect cpu_slab->freelist using only cpu_slab->freelist
with less overhead. That's why I'm asking if there's any other reason for TID.
next prev parent reply other threads:[~2021-11-23 12:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-21 14:11 Wonhyuk Yang
2021-11-22 9:25 ` Christoph Lameter
2021-11-23 3:32 ` Wonhyuk Yang
2021-11-23 9:38 ` Christoph Lameter
2021-11-23 12:18 ` Wonhyuk Yang [this message]
2021-11-23 12:30 ` Wonhyuk Yang
2021-11-23 13:54 ` Christoph Lameter
2021-11-23 23:59 ` Wonhyuk Yang
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=CAEcHRTrTc-DzeyU4fetfyU3pQCS6A0pPexGe5c5yB94Z88ueHg@mail.gmail.com \
--to=vvghjk1234@gmail.com \
--cc=cl@gentwo.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.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