Skip to contentSkip to conversation

Expedite srcu_schedule_cbs_snp() callback invocation

RFC PATCH In review Paul E. McKenney 2 participants 3 messages Apr 18, 2017 Sleepable read-copy update (SRCU)

lore
Share & tools
lore
#0 lore raw

RFC PATCH 1/1 Expedite srcu_schedule_cbs_snp() callback invocation

Although Tree SRCU does reduce delays when there is at least one synchronize_srcu_expedited() invocation pending, srcu_schedule_cbs_snp() still waits for SRCU_INTERVAL before invoking callbacks. Since synchronize_srcu_expedited() now posts a callback and waits for that callback to do a wakeup, this destroys the expedited nature of synchronize_srcu_expedited().

This commit therefore invokes callbacks immediately at the end of the grace period when there is at least one synchronize_srcu_expedited() invocation pending.

kernel/rcu/srcutree.c +2 -1
index 1e54f91c2ff7..744ffdb79d23 100644
@@ -447,7 +447,8 @@ static void srcu_schedule_cbs_snp(struct srcu_struct *sp, struct srcu_node *snp)
 	int cpu;
 
 	for (cpu = snp->grplo; cpu <= snp->grphi; cpu++)
-		srcu_schedule_cbs_sdp(per_cpu_ptr(sp->sda, cpu), SRCU_INTERVAL);
+		srcu_schedule_cbs_sdp(per_cpu_ptr(sp->sda, cpu),
+				      atomic_read(&sp->srcu_exp_cnt) ? 0 : SRCU_INTERVAL);
 }
 
 /*
Tested-by on v1 1/1
#1 lore raw
Quoted 19 lines · Paul E. McKenney

Although Tree SRCU does reduce delays when there is at least one synchronize_srcu_expedited() invocation pending, srcu_schedule_cbs_snp() still waits for SRCU_INTERVAL before invoking callbacks. Since synchronize_srcu_expedited() now posts a callback and waits for that callback to do a wakeup, this destroys the expedited nature of synchronize_srcu_expedited().

This commit therefore invokes callbacks immediately at the end of the grace period when there is at least one synchronize_srcu_expedited() invocation pending.

kernel/rcu/srcutree.c +0 -0
index 1e54f91c2ff7..744ffdb79d23 100644

kernel/rcu/srcutree.c static void srcu_schedule_cbs_snp(struct srcu_struct *sp, struct srcu_node *snp) · line 454

Quoted 9 lines
kernel/rcu/srcutree.c +2 -1
@@ -447,7 +447,8 @@ static void srcu_schedule_cbs_snp(struct srcu_struct *sp, struct srcu_node *snp)
 	int cpu;
 
 	for (cpu = snp->grplo; cpu <= snp->grphi; cpu++)
-		srcu_schedule_cbs_sdp(per_cpu_ptr(sp->sda, cpu), SRCU_INTERVAL);
+		srcu_schedule_cbs_sdp(per_cpu_ptr(sp->sda, cpu),
+				      atomic_read(&sp->srcu_exp_cnt) ? 0 : SRCU_INTERVAL);
 }
 
 /*

This fixes the issue I was observing, where UEFI in a KVM guest would take a x8 slowdown while it messes with some NOR flash emulation on arm64 (don't ask, this is horrible...). Anyway:

Thanks again Paul!

	M.
Signature · 1 line
Jazz is not dead. It just smells funny...
author Tested-by Marc Zyngier
#2 lore raw
Quoted 34 lines · Marc Zyngier
Quoted 19 lines · Paul E. McKenney

Although Tree SRCU does reduce delays when there is at least one synchronize_srcu_expedited() invocation pending, srcu_schedule_cbs_snp() still waits for SRCU_INTERVAL before invoking callbacks. Since synchronize_srcu_expedited() now posts a callback and waits for that callback to do a wakeup, this destroys the expedited nature of synchronize_srcu_expedited().

This commit therefore invokes callbacks immediately at the end of the grace period when there is at least one synchronize_srcu_expedited() invocation pending.

kernel/rcu/srcutree.c +0 -0
index 1e54f91c2ff7..744ffdb79d23 100644

kernel/rcu/srcutree.c static void srcu_schedule_cbs_snp(struct srcu_struct *sp, struct srcu_node *snp) · line 454

Quoted 9 lines
kernel/rcu/srcutree.c +2 -1
@@ -447,7 +447,8 @@ static void srcu_schedule_cbs_snp(struct srcu_struct *sp, struct srcu_node *snp)
 	int cpu;
 
 	for (cpu = snp->grplo; cpu <= snp->grphi; cpu++)
-		srcu_schedule_cbs_sdp(per_cpu_ptr(sp->sda, cpu), SRCU_INTERVAL);
+		srcu_schedule_cbs_sdp(per_cpu_ptr(sp->sda, cpu),
+				      atomic_read(&sp->srcu_exp_cnt) ? 0 : SRCU_INTERVAL);
 }
 
 /*

This fixes the issue I was observing, where UEFI in a KVM guest would take a x8 slowdown while it messes with some NOR flash emulation on arm64 (don't ask, this is horrible...). Anyway:

Quoted 3 lines

Thanks again Paul!

Thank you for your bug-finding and testing efforts! I will be pushing this into the upcoming merge window.

Thanx, Paul

------------------------------------------------------------------------

commit 6eec94fe40e294b04d32c8ef552e28fa6159bdad

Author: Paul E. McKenney <[email protected]>
Date:   Tue Apr 18 10:28:31 2017 -0700

srcu: Expedite srcu_schedule_cbs_snp() callback invocation

Although Tree SRCU does reduce delays when there is at least one synchronize_srcu_expedited() invocation pending, srcu_schedule_cbs_snp() still waits for SRCU_INTERVAL before invoking callbacks. Since synchronize_srcu_expedited() now posts a callback and waits for that callback to do a wakeup, this destroys the expedited nature of synchronize_srcu_expedited(). This destruction became apparent to Marc Zyngier in the guise of a guest-OS bootup slowdown from five seconds to no fewer than forty seconds.

This commit therefore invokes callbacks immediately at the end of the grace period when there is at least one synchronize_srcu_expedited() invocation pending. This brought Marc's guest-OS bootup times back into the realm of reason.

kernel/rcu/srcutree.c +2 -1
index 1e54f91c2ff7..744ffdb79d23 100644
@@ -447,7 +447,8 @@ static void srcu_schedule_cbs_snp(struct srcu_struct *sp, struct srcu_node *snp)
 	int cpu;
 
 	for (cpu = snp->grplo; cpu <= snp->grphi; cpu++)
-		srcu_schedule_cbs_sdp(per_cpu_ptr(sp->sda, cpu), SRCU_INTERVAL);
+		srcu_schedule_cbs_sdp(per_cpu_ptr(sp->sda, cpu),
+				      atomic_read(&sp->srcu_exp_cnt) ? 0 : SRCU_INTERVAL);
 }
 
 /*