[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aFwIHnSr8lok7Gks@localhost.localdomain>
Date: Wed, 25 Jun 2025 16:30:54 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Tejun Heo <tj@...nel.org>
Cc: Waiman Long <llong@...hat.com>, LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
Marco Crivellari <marco.crivellari@...e.com>,
Michal Hocko <mhocko@...e.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH 02/27] sched/isolation: Introduce housekeeping per-cpu
rwsem
Le Mon, Jun 23, 2025 at 08:03:46AM -1000, Tejun Heo a écrit :
> Hello,
>
> On Mon, Jun 23, 2025 at 01:57:17PM -0400, Waiman Long wrote:
> > The percpu-rwsem does have a cheaper read side compared with rwsem for
> > typical use case where writer update happens sparingly. However, when the
> > writer has successful acquired the write lock, the readers do have to wait
> > until the writer issues a percpu_up_write() call before they can proceed. It
> > is the delay introduced by this wait that I am worry about. Isolated
> > partitions are typically set up to run RT applications that have a strict
> > latency requirement. So any possible latency spike should be avoided.
>
> I see. Hmm... this being the mechanism that establishes the isolation, it
> doesn't seem too broken if things stutter a bit when isolation is being
> updated. Let's see what Frederic says why the strong interlocking is needed.
I should be able to work around that.
I think only PCI requires that rwsem because it relies on work_on_cpu().
I can create a dedicated workqueue for it that housekeeping can flush after
the cpumask update.
--
Frederic Weisbecker
SUSE Labs
Powered by blists - more mailing lists