On most architectures (arm, mips, s390, sh and x86) idle thread of a cpu does
not cleanly exit nohz state before dying upon hot-remove. As a result,
offline cpu is seen to be in nohz mode (ts->idle_active = 1) and its offline
time can potentially be included in total idle time reported via /proc/st
ngo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: mho...@suse.cz
Cc: srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Srivatsa Vaddagiri
---
arch/arm/kernel/process.c |9 -
arch/arm/kernel/smp.c |2 +-
arch/blackfin/kernel/process.c |8
ar
time statistics).
Cc: mho...@suse.cz
Cc: srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Srivatsa Vaddagiri
---
fs/proc/stat.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/fs/proc/stat.c b/fs/proc/stat.c
index e296572..64c3b31 100644
--- a/fs/proc/stat
* Sergei Shtylyov [2013-01-04 16:13:42]:
> >With offline cpus no longer beeing seen in nohz mode (ts->idle_active=0), we
> >don't need the check for cpu_online() introduced in commit 7386cdbf. Offline
>
>Please also specify the summary of that commit in parens (or
> however you like).
I had
* Russell King - ARM Linux [2013-01-05 10:36:27]:
> On Thu, Jan 03, 2013 at 06:58:38PM -0800, Srivatsa Vaddagiri wrote:
> > I also think that the
> > wait_for_completion() based wait in ARM's __cpu_die() can be replaced with a
> > busy-loop based one, as the wait
nfluence by RT tasks or freq scaling. Note that at core level,
capacity is unchanged and hence this affects only how tasks are distributed
within a core.
Mike Neuling should post an updated patchset containing this patch
(with more comments added ofcourse!).
Signed-off-by: Srivatsa Vaddagiri
--
On Fri, Jan 25, 2008 at 09:50:00AM +0100, Peter Zijlstra wrote:
>
> On Fri, 2008-01-25 at 18:25 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2008-01-25 at 18:03 +1100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2008-01-25 at 17:54 +1100, Benjamin Herrenschmidt wrote:
> > > >
> > > > Here, I
On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
> > Ben,
> > I presume you had CONFIG_FAIR_USER_SCHED turned on too?
>
> Yes. It seems to be automatically turned on whenever FAIR_GROUP is
> turned on. Considering how bad the behaviour is for a standard desktop
> con
On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
> > Ben,
> > I presume you had CONFIG_FAIR_USER_SCHED turned on too?
>
> Yes. It seems to be automatically turned on whenever FAIR_GROUP is
> turned on. Considering how bad the behaviour is for a standard desktop
> con
On Sat, Jan 26, 2008 at 04:15:52PM +1100, Benjamin Herrenschmidt wrote:
> > Michel,
> > You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> > was the cause for this bad behavior. Do you see behavior change (from
> > good->bad)
> > immediately after applying that patch duri
On Mon, Jan 28, 2008 at 10:14:33AM +0100, Michel Dänzer wrote:
> > > * With CONFIG_FAIR_USER_SCHED enabled, X becomes basically
> > > unusable with a niced CPU hog, with or without top running. I
> > > don't know when this started, possibly when this option was
> > > f
On Mon, Jan 28, 2008 at 01:32:53PM +0100, Ingo Molnar wrote:
> * Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > > * With CONFIG_FAIR_USER_SCHED disabled, there are severe
> > > interactivity hickups with a niced CPU hog and top running. This
> > > started with commit 810e95c
12 matches
Mail list logo
