All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ihor Solodrai <ihor.solodrai@linux.dev>,
	Shrikanth Hegde <sshegde@linux.ibm.com>,
	Michael Jeanson <mjeanson@efficios.com>
Subject: Re: [patch V2 0/4] sched/mmcid: Cure mode transition woes
Date: Wed, 04 Feb 2026 11:53:48 +0100	[thread overview]
Message-ID: <87v7gc230j.ffs@tglx> (raw)
In-Reply-To: <20260202125430.GD1395266@noisy.programming.kicks-ass.net>

On Mon, Feb 02 2026 at 13:54, Peter Zijlstra wrote:
> On Mon, Feb 02, 2026 at 06:46:34AM -0500, Mathieu Desnoyers wrote:
>> On 2026-02-02 05:14, Peter Zijlstra wrote:
>> > On Mon, Feb 02, 2026 at 10:39:35AM +0100, Thomas Gleixner wrote:
>> > 
>> > > --- a/kernel/sched/core.c
>> > > +++ b/kernel/sched/core.c
>> > > @@ -10445,6 +10445,12 @@ static bool mm_update_max_cids(struct mm
>> > >   	/* Flip the mode and set the transition flag to bridge the transfer */
>> > >   	WRITE_ONCE(mc->mode, mc->mode ^ (MM_CID_TRANSIT | MM_CID_ONCPU));
>> > > +	/*
>> > > +	 * Order the store against the subsequent fixups so that
>> > > +	 * acquire(rq::lock) cannot be reordered by the CPU before the
>> > > +	 * store.
>> > > +	 */
>> > > +	smp_mb();
>> > >   	return true;
>> > >   }
>> > > @@ -10487,6 +10493,16 @@ static inline void mm_update_cpus_allowe
>> > >   	irq_work_queue(&mc->irq_work);
>> > >   }
>> > > +static inline void mm_cid_complete_transit(struct mm_struct *mm, unsigned int mode)
>> > > +{
>> > > +	/*
>> > > +	 * Ensure that the store removing the TRANSIT bit cannot be
>> > > +	 * reordered by the CPU before the fixups have been completed.
>> > > +	 */
>> > > +	smp_mb();
>> > > +	WRITE_ONCE(mm->mm_cid.mode, mode);
>> > > +}
>> > 
>> > I think this could've been smp_store_release(), but this is the slow
>> > path so nobody cares and this is nicely symmetric.
>> 
>> I'm not sure the store-release would work here. What load-acquire
>> would it pair with ?
>
> The purpose here -- per the comment is to ensure the fixup stuff is
> visible before the TRANSIT bit goes 0, store-release ensures that.
>
> That pairs with whatever cares about this barrier now.

I thought about this and stopped reading memory-barriers.txt after brain
started to hurt.

        acquire A
        store   B
        release A

        acquire C
        store   D
        release C

A and C are independent of each other as are B and D. So according to
the docs acquire C can be reordered before release A. So far so
good. But what's unclear to me is whether this scenarion is possible:

        acquire A
        acquire C
        store   D
        release C
        store   B
        release A

because that would screw up stuff badly.

Thanks,

        tglx


      parent reply	other threads:[~2026-02-04 10:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-02  9:39 [patch V2 0/4] sched/mmcid: Cure mode transition woes Thomas Gleixner
2026-02-02  9:39 ` [patch V2 1/4] sched/mmcid: Prevent live lock on task to CPU mode transition Thomas Gleixner
2026-02-02 14:50   ` Mathieu Desnoyers
2026-02-04 13:27   ` [tip: sched/urgent] " tip-bot2 for Thomas Gleixner
2026-02-02  9:39 ` [patch V2 2/4] sched/mmcid: Protect transition on weakly ordered systems Thomas Gleixner
2026-02-02 14:53   ` Mathieu Desnoyers
2026-02-04 13:27   ` [tip: sched/urgent] " tip-bot2 for Thomas Gleixner
2026-02-02  9:39 ` [patch V2 3/4] sched/mmcid: Drop per CPU CID immediately when switching to per task mode Thomas Gleixner
2026-02-04 13:27   ` [tip: sched/urgent] " tip-bot2 for Thomas Gleixner
2026-02-10  7:33   ` [patch V2 3/4] " Shinichiro Kawasaki
2026-02-10 10:44     ` Thomas Gleixner
2026-02-10 11:51       ` Shinichiro Kawasaki
2026-02-10 13:03         ` Peter Zijlstra
2026-02-10 14:15           ` Shinichiro Kawasaki
2026-02-10 13:33         ` Thomas Gleixner
2026-02-10 14:55           ` Shinichiro Kawasaki
2026-02-10 16:20             ` [PATCH] sched/mmcid: Don't assume CID is CPU owned on mode switch Thomas Gleixner
2026-02-10 16:28               ` Mathieu Desnoyers
2026-02-11 10:33               ` Takashi Iwai
2026-02-11 21:00               ` Linus Torvalds
2026-02-02  9:39 ` [patch V2 4/4] sched/mmcid: Optimize transitional CIDs when scheduling out Thomas Gleixner
2026-02-02 14:56   ` Mathieu Desnoyers
2026-02-04 13:27   ` [tip: sched/urgent] " tip-bot2 for Thomas Gleixner
2026-02-02 10:14 ` [patch V2 0/4] sched/mmcid: Cure mode transition woes Peter Zijlstra
2026-02-02 11:46   ` Mathieu Desnoyers
2026-02-02 12:54     ` Peter Zijlstra
2026-02-02 21:22       ` Mathieu Desnoyers
2026-02-04 10:53       ` Thomas Gleixner [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=87v7gc230j.ffs@tglx \
    --to=tglx@kernel.org \
    --cc=ihor.solodrai@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mjeanson@efficios.com \
    --cc=peterz@infradead.org \
    --cc=sshegde@linux.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.