> I agree with the problem but disagree with the patch because it feels like a
> terrible workaround.
>
> Can we just use arch_spin_lock() for the cpu_asid_lock? This might require
> acquiring the raw_lock within the raw_spinlock_t, but there is precedent:
>
> arch/powerpc/kvm/book3s_hv_rm_mmu.c:
Unconditionally honor guest PAT on CPUs that support self-snoop, as
Intel has confirmed that CPUs that support self-snoop always snoop caches
and store buffers. I.e. CPUs with self-snoop maintain cache coherency
even in the presence of aliased memtypes, thus there is no need to trust
the guest beh
From: Yan Zhao
Ensure a full memory barrier is emitted in the VM-Exit path, as a full
barrier is required on Intel CPUs to evict WC buffers. This will allow
unconditionally honoring guest PAT on Intel CPUs that support self-snoop.
As srcu_read_lock() is always called in the VM-Exit path and it
From: Yan Zhao
To avoid redundant memory barriers, add smp_mb__after_srcu_read_lock() to
pair with smp_mb__after_srcu_read_unlock() for use in paths that need to
emit a memory barrier, but already do srcu_read_lock(), which includes a
full memory barrier. Provide an API, e.g. as opposed to havin
Drop KVM's emulation of CR0.CD=1 on Intel CPUs now that KVM no longer
honors guest MTRR memtypes, as forcing UC memory for VMs with
non-coherent DMA only makes sense if the guest is using something other
than PAT to configure the memtype for the DMA region.
Furthermore, KVM has forced WB memory fo
Remove KVM's support for virtualizing guest MTRR memtypes, as full MTRR
adds no value, negatively impacts guest performance, and is a maintenance
burden due to it's complexity and oddities.
KVM's approach to virtualizating MTRRs make no sense, at all. KVM *only*
honors guest MTRR memtypes if EPT
First, rip out KVM's support for virtualizing guest MTRRs on VMX. The
code is costly to main, a drag on guest boot performance, imperfect, and
not required for functional correctness with modern guest kernels. Many
details in patch 1's changelog.
With MTRR virtualization gone, always honor guest
On 3/8/2024 4:52 PM, Paul E. McKenney wrote:
> On Fri, Mar 08, 2024 at 06:38:37PM +0100, Uladzislau Rezki wrote:
>> On Fri, Mar 08, 2024 at 04:05:15PM +0100, Uladzislau Rezki wrote:
>>> On Thu, Mar 07, 2024 at 04:06:06PM -0800, Paul E. McKenney wrote:
On Thu, Mar 07, 2024 at 06:52:14PM -050
This a confusing piece of code (rightfully so as the issue it deals with
is complex). Recent discussions brought up a question -- what prevents the
rcu_implicit_dyntick_qs() from warning about QS reports for offline
CPUs.
QS reporting for now-offline CPUs should only happen from:
- gp_init()
- rcu
In the synchronize_rcu() common case, we will have less than
SR_MAX_USERS_WAKE_FROM_GP number of users per GP. Waking up the kworker
is pointless just to free the last injected wait head since at that point,
all the users have already been awakened.
Introduce a new counter to track this and preven
On Fri, Mar 08, 2024 at 11:02:28PM +0100, Marco Elver wrote:
> On Fri, 8 Mar 2024 at 22:41, Paul E. McKenney wrote:
> >
> > Tasks Trace RCU needs a single-byte cmpxchg(), but no such thing exists.
>
> Because not all architectures support 1-byte cmpxchg?
> What prevents us from implementing it?
Le Thu, Mar 07, 2024 at 06:48:51PM -0500, Joel Fernandes (Google) a écrit :
> In the synchronize_rcu() common case, we will have less than
> SR_MAX_USERS_WAKE_FROM_GP number of users per GP. Waking up the kworker
> is pointless just to free the last injected wait head since at that point,
> all the
On Fri, 8 Mar 2024 at 22:41, Paul E. McKenney wrote:
>
> Tasks Trace RCU needs a single-byte cmpxchg(), but no such thing exists.
Because not all architectures support 1-byte cmpxchg?
What prevents us from implementing it?
> Therefore, rcu_trc_cmpxchg_need_qs() emulates one using field substitut
On Fri, Mar 08, 2024 at 06:38:37PM +0100, Uladzislau Rezki wrote:
> On Fri, Mar 08, 2024 at 04:05:15PM +0100, Uladzislau Rezki wrote:
> > On Thu, Mar 07, 2024 at 04:06:06PM -0800, Paul E. McKenney wrote:
> > > On Thu, Mar 07, 2024 at 06:52:14PM -0500, Joel Fernandes wrote:
> > > > On Thu, Mar 7, 20
On Fri, Mar 08, 2024 at 06:34:03PM +0100, Uladzislau Rezki (Sony) wrote:
> This is v6. It is based on the Paul's "dev" branch:
>
> HEAD: f1bfe538c7970283040a7188a291aca9f18f0c42
>
> please note, that patches should be applied from scratch,
> i.e. the v5 has to be dropped from the "dev".
>
> v5 -
Tasks Trace RCU needs a single-byte cmpxchg(), but no such thing exists.
Therefore, rcu_trc_cmpxchg_need_qs() emulates one using field substitution
and a four-byte cmpxchg(), such that the other three bytes are always
atomically updated to their old values. This works, but results in
false-positiv
On Fri, Mar 08, 2024 at 04:05:15PM +0100, Uladzislau Rezki wrote:
> On Thu, Mar 07, 2024 at 04:06:06PM -0800, Paul E. McKenney wrote:
> > On Thu, Mar 07, 2024 at 06:52:14PM -0500, Joel Fernandes wrote:
> > > On Thu, Mar 7, 2024 at 6:48 PM Joel Fernandes (Google)
> > > wrote:
> > > >
> > > > In the
synchronize_rcu() users have to be processed regardless
of memory pressure so our private WQ needs to have at least
one execution context what WQ_MEM_RECLAIM flag guarantees.
Reviewed-by: Joel Fernandes (Google)
---
kernel/rcu/tree.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
di
Fix a below race by not releasing a wait-head from the
GP-kthread as it can lead for reusing it whereas a worker
can still access it thus execute newly added callbacks too
early.
CPU 0 CPU 1
- -
// wait_tail == HEAD1
rcu_sr_normal_
This patch introduces a small enhancement which allows to do a
direct wake-up of synchronize_rcu() callers. It occurs after a
completion of grace period, thus by the gp-kthread.
Number of clients is limited by the hard-coded maximum allowed
threshold. The remaining part, if still exists is deferre
A call to a synchronize_rcu() can be optimized from a latency
point of view. Workloads which depend on this can benefit of it.
The delay of wakeme_after_rcu() callback, which unblocks a waiter,
depends on several factors:
- how fast a process of offloading is started. Combination of:
- !CONFI
Add an rcu_sr_normal() trace event. It takes three arguments
first one is the name of RCU flavour, second one is a user id
which triggeres synchronize_rcu_normal() and last one is an
event.
There are two traces in the synchronize_rcu_normal(). On entry,
when a new request is registered and on exit
The synchronize_rcu() call is going to be reworked, thus
this patch adds dedicated fields into the rcu_state structure.
Signed-off-by: Uladzislau Rezki (Sony)
---
kernel/rcu/tree.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index df4
This is v6. It is based on the Paul's "dev" branch:
HEAD: f1bfe538c7970283040a7188a291aca9f18f0c42
please note, that patches should be applied from scratch,
i.e. the v5 has to be dropped from the "dev".
v5 -> v6:
- Fix a race due to realising a wait-head from the gp-kthread;
- Use our own priv
Hi Linus,
Please pull this for the RCU changes of v6.9:
The following changes since commit 41bccc98fb7931d63d03f326a746ac4d429c1dd3:
Linux 6.8-rc2 (2024-01-28 17:01:12 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/boqun/linux.git
tags/rcu.nex
On Thu, Mar 07, 2024 at 04:06:06PM -0800, Paul E. McKenney wrote:
> On Thu, Mar 07, 2024 at 06:52:14PM -0500, Joel Fernandes wrote:
> > On Thu, Mar 7, 2024 at 6:48 PM Joel Fernandes (Google)
> > wrote:
> > >
> > > In the synchronize_rcu() common case, we will have less than
> > > SR_MAX_USERS_WAKE
On 3/7/2024 11:09 AM, Stefan Wiehler wrote:
> With CONFIG_PROVE_RCU_LIST=y and by executing
>
> $ echo 0 > /sys/devices/system/cpu/cpu1/online
>
> one can trigger the following Lockdep-RCU splat on ARM:
>
> =
> WARNING: suspicious RCU usage
> 6.8.0-rc7-
> I'm not sure this is a false-positive: if you traverse an RCU-list
> without RCU watching the CPU, then a grace period may pass, the next
> list can be garbage and you can go anywhere from the list. Or am I
> missing something that a CPU hotplug can block a grace period?
Thanks for the feedback!
28 matches
Mail list logo
