All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shrikanth Hegde <sshegde@linux.ibm.com>
To: Jirka Hladky <jhladky@redhat.com>
Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
	paulmck@kernel.org, maddy@linux.ibm.com,
	linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au,
	npiggin@gmail.com, bigeasy@linutronix.de, will@kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/1] powerpc: enable dynamic preemption
Date: Fri, 31 Jul 2026 23:27:06 +0530	[thread overview]
Message-ID: <1eab63fc-b70d-41ef-b720-8ae77d8e56d8@linux.ibm.com> (raw)
In-Reply-To: <CAE4VaGDQ0Ysdfhqc-eF9Oby-QkZxiL-TvS-WkJ_KKEVrRvTc7Q@mail.gmail.com>

Hi Jirka.

On 7/31/26 7:20 PM, Jirka Hladky wrote:
> On Fri, Jul 31, 2026 at 10:03 AM Shrikanth Hegde <sshegde@linux.ibm.com> wrote:
>> Coming into numbers, I did notice later, arm64 numbers are almost 20x less.
>> But if we compare the time taken for each operations, it tells a
>> different story.

> 
> The bottom line: PREEMPT_DYNAMIC/preempt_count overhead is present
> on both RISC architectures but its visibility depends heavily on the
> workload profile and hardware topology.
> 
>> PS: I tried porting some of those changes in arm64 to powerpc to
>> split preempt count into two. but i don;t see much improvement
>> there.

I tried moving to PACA plus splitting 64 bit into need_resched and preempt
count. But it doesn;t move the needle. But it maybe worth pursuing,
since it could help preemption modes. It needs more work and needs numbers
across benchmark.

> 
> Thanks for trying. Paul questioned whether barriers are actually
> needed for preempt_count, or whether software interrupt disabling
> would suffice (his words: "I can see why the preempt_count()
> operations need to be interrupt-safe, but I don't see why you would
> need barriers"). Any thoughts on whether that's feasible for
> powerpc?
> 

Barrier are likely not the concern as it is mostly nop.
Also, soft disabling interrupts needs to arch specific hooks to setup
before preempt_disable and replay interrupts after preempt_enable.
I don't think it would benefit since interrupt disabling during this likely
shouldn't happen. Maybe I don't understand how that could work.


  reply	other threads:[~2026-07-31 17:57 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-10 18:43 [PATCH v4 0/1] powerpc: Enable dynamic preemption Shrikanth Hegde
2025-02-10 18:43 ` [PATCH v4 1/1] powerpc: enable " Shrikanth Hegde
2026-07-26 18:33   ` Jirka Hladky
2026-07-27  4:18     ` Shrikanth Hegde
2026-07-27 10:13       ` Jirka Hladky
2026-07-27 10:28         ` Shrikanth Hegde
2026-07-27 10:35           ` Christophe Leroy (CS GROUP)
2026-07-27 16:12             ` Paul E. McKenney
2026-07-27 10:59           ` Jirka Hladky
2026-07-27 11:03             ` Shrikanth Hegde
2026-07-27 12:34         ` Shrikanth Hegde
2026-07-27 16:07       ` Paul E. McKenney
2026-07-27 16:50         ` Jirka Hladky
2026-07-27 17:10           ` Shrikanth Hegde
2026-07-27 18:29             ` Christophe Leroy (CS GROUP)
2026-07-28  5:27               ` Shrikanth Hegde
2026-07-28 16:21                 ` Paul E. McKenney
2026-07-28 16:30                   ` Paul E. McKenney
2026-07-30 13:01                   ` Shrikanth Hegde
2026-07-30 14:51                     ` Paul E. McKenney
2026-07-28  0:26             ` Jirka Hladky
2026-07-28  5:11               ` Shrikanth Hegde
2026-07-28 14:19                 ` Jirka Hladky
2026-07-30  6:44                   ` Shrikanth Hegde
2026-07-30 12:08                     ` Jirka Hladky
2026-07-30 14:47                       ` Paul E. McKenney
2026-07-30 15:08                         ` Jirka Hladky
2026-07-30 16:26                           ` Paul E. McKenney
2026-07-30 17:10                           ` Shrikanth Hegde
2026-07-30 17:26                             ` Paul E. McKenney
2026-07-30 18:40                               ` Segher Boessenkool
2026-07-31  4:59                                 ` Christophe Leroy (CS GROUP)
2026-07-31  5:03                             ` Christophe Leroy (CS GROUP)
2026-07-31  7:18                               ` Jirka Hladky
2026-07-31  8:02                                 ` Shrikanth Hegde
2026-07-31 13:50                                   ` Jirka Hladky
2026-07-31 17:57                                     ` Shrikanth Hegde [this message]
2026-07-31 18:11                                       ` Paul E. McKenney
2026-08-03  4:51                                         ` Shrikanth Hegde
2026-08-03 15:27                                           ` Paul E. McKenney

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=1eab63fc-b70d-41ef-b720-8ae77d8e56d8@linux.ibm.com \
    --to=sshegde@linux.ibm.com \
    --cc=bigeasy@linutronix.de \
    --cc=chleroy@kernel.org \
    --cc=jhladky@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=will@kernel.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 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.