>>> On 26.09.17 at 19:48, wrote:
> On Tue, 2017-09-26 at 09:14 -0600, Jan Beulich wrote:
>> > > > On 15.09.17 at 20:01, wrote:
>> > --- a/xen/common/rcupdate.c
>> > +++ b/xen/common/rcupdate.c
>> > +int ret = 0;
>> > +
>> > +if (
On Tue, 2017-09-26 at 09:14 -0600, Jan Beulich wrote:
> > > > On 15.09.17 at 20:01, wrote:
> > --- a/xen/common/rcupdate.c
> > +++ b/xen/common/rcupdate.c
> > +int ret = 0;
> > +
> > +if ( MILLISECS(period) > IDLE_TIMER_PERIOD_MAX )
> > +{
> > +
>>> On 15.09.17 at 20:01, wrote:
> --- a/xen/common/rcupdate.c
> +++ b/xen/common/rcupdate.c
> @@ -110,10 +110,35 @@ struct rcu_data {
> * About how far in the future the timer should be programmed each time,
> * it's hard to tell (guess!!). Since this mimics
Make it possible for the user to specify, with the boot
time parameter rcu_idle_timer_period_ms, how frequently
a CPU that went idle with pending RCU callbacks should be
woken up to check if the grace period ended.
Typical values (i.e., some of the values used by Linux as
the tick frequency) are