On Thu, 21 Jan 2016, Shiraz Hashim wrote:
> > On idle we fold counters immediately. So there is no loss of accuracy.
>
> vmstat is scheduled by shepherd or by itself (conditionally). In case shepherd
> is deferred and vmstat doesn't schedule itself, then vmstat needs to wait
> for shepherd to be u
On Wed, Jan 20, 2016 at 8:42 PM, Christoph Lameter wrote:
> On Wed, 20 Jan 2016, Shiraz Hashim wrote:
>
>> The patch makes vmstat_shepherd deferable which if is quiesed
>> would not schedule vmstat update on other cpus. Wouldn't this
>> aggravate the problem of vmstat for rest cpus not gettng upda
On Wed, 20 Jan 2016, Shiraz Hashim wrote:
> The patch makes vmstat_shepherd deferable which if is quiesed
> would not schedule vmstat update on other cpus. Wouldn't this
> aggravate the problem of vmstat for rest cpus not gettng updated.
Its only "deferred" in order to make it at the next tick an
Hmmm... We got a race condition since quiet_vmstat touches cpu_stat_off
which may not be allocated early in the bootup sequence. Causes oopses on
boot.
Subject: vmstat: quieting vmstat requires a running system
Do not do anything unless the system is actually running. Otherwise
we may crash on
On Thu, 10 Dec 2015, Andrew Morton wrote:
> > /*
> > + * Switch off vmstat processing and then fold all the remaining
> > differentials
> > + * until the diffs stay at zero. The function is used by NOHZ and can only
> > be
> > + * invoked when tick processing is not active.
> > + */
> > +void q
On Thu, 10 Dec 2015 14:45:02 -0600 (CST) Christoph Lameter
wrote:
> Currently the vmstat updater is not deferrable as a result of commit
> ba4877b9ca51f80b5d30f304a46762f0509e1635. This in turn can cause multiple
> interruptions of the applications because the vmstat updater may run at
> differe
6 matches
Mail list logo
