[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 5/5] xen: RCU: avoid busy waiting until the end of grace period.
On 01/08/2017 00:58, Stefano Stabellini wrote:
On Tue, 1 Aug 2017, Dario Faggioli wrote:
On Mon, 2017-07-31 at 14:20 -0700, Stefano Stabellini wrote:
On Thu, 27 Jul 2017, Dario Faggioli wrote:
diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c
index f0fdc87..4586f2a 100644
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -84,8 +84,14 @@ struct rcu_data {
int cpu;
struct rcu_head barrier;
long last_rs_qlen; /* qlen during the last
resched */
+
+ /* 3) idle CPUs handling */
+ struct timer idle_timer;
+ bool idle_timer_active;
};
+#define RCU_IDLE_TIMER_PERIOD MILLISECS(10)
Isn't this a bit too short? How is it chosen?
It's totally arbitrary (and that would be the case for whatever value
we choose).
Basically, it's how long, at worst, after the actual end of a grace
period, a (batch of) callback(s) will be invoked. Currently, on Credit1
on ARM (without my patch, from this series, that suspends the tick)
that's (by chance) 30 ms (or whatever value is chosen for Credit1
timeslice). On Credit2 (on both ARM and x86), it's never, but on x86 it
(apparently) is 'however frequent time sync rendezvouses happs' (which
I don't recall, but it's longer), while on ARM is (potentially) never.
I accept suggestions about alternatives values, and I'm certainly fine
with adding a comment, containing something along the lines of the
explanation above, but I fear it's going to be hard to figure out what
value is actually the "absolute best".
In Linux (which is where the same 'callback book-keeping' happens for
them), a tick with a frequency of 1000Hz (== 1ms) is considered 'low-
latency/Deskop/real-time'. For us, as said above, tick --when it's
there-- would be 30ms by default.
I just went with something in the middle.
Also, it's not that we'll have a 10ms periodic timer going on for
significant amount of time. In fact we expect it to actually fire just
once (for each grace period). It's not 100% guaranteed that it won't be
reprogrammed and fire a couple of times, but it should not, in the vast
majority of cases.
What makes you think it's short?
In terms of power saving and CPU sleep states, 10ms is not much to sleep
for. I wonder if there are any power saving benefits in sleeping for
only 10ms (especially on x86 where entering and exiting CPU sleep states
takes longer, to be confirmed). We might as well do the thing we need
to do immediately? I guess we cannot do that?
Given that on ARM we use WFI to sleep today, I think we can already
benefit some power saving even for 10ms. Although, it will depend on the
processor.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
