linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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.


  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