[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1289843441.2109.520.camel@laptop>
Date: Mon, 15 Nov 2010 18:50:41 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Martin Schwidefsky <schwidefsky@...ibm.com>
Cc: Michael Holzheu <holzheu@...ux.vnet.ibm.com>,
Shailabh Nagar <nagar1234@...ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Venkatesh Pallipadi <venki@...gle.com>,
Suresh Siddha <suresh.b.siddha@...el.com>,
Ingo Molnar <mingo@...e.hu>, Oleg Nesterov <oleg@...hat.com>,
John stultz <johnstul@...ibm.com>,
Thomas Gleixner <tglx@...utronix.de>,
Balbir Singh <balbir@...ux.vnet.ibm.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Roland McGrath <roland@...hat.com>,
linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
"jeremy.fitzhardinge" <jeremy.fitzhardinge@...rix.com>
Subject: Re: [RFC][PATCH v2 4/7] taskstats: Add per task steal time
accounting
On Mon, 2010-11-15 at 18:42 +0100, Martin Schwidefsky wrote:
> The steal time of a task tells us how much more progress a task could have
> done if the hypervisor would not steal cpu. Now you could argue that the
> steal time for a cpu is good enough for that purpose but steal time is not
> necessarily uniform over all tasks. And we already do calculate this number,
> we just do not store it right now.
If you make the scheduler take steal time into account like Jeremy
proposed then you schedule on serviced time and the steal time gain is
proportional to the existing service distribution.
Still, then you know, then what are you going to do about it? Are you
going to avoid the hypervisor from scheduling when that one task is
running?
What good is knowing something you cannot do anything about.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists