[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070314135845.GG22466@csclub.uwaterloo.ca>
Date: Wed, 14 Mar 2007 09:58:45 -0400
From: lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To: Jeremy Fitzhardinge <jeremy@...p.org>
Cc: Dan Hecht <dhecht@...are.com>, dwalker@...sta.com,
cpufreq@...ts.linux.org.uk,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Con Kolivas <kernel@...ivas.org>,
Chris Wright <chrisw@...s-sol.org>,
Virtualization Mailing List <virtualization@...ts.osdl.org>,
john stultz <johnstul@...ibm.com>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Stolen and degraded time and schedulers
On Tue, Mar 13, 2007 at 09:37:59PM -0700, Jeremy Fitzhardinge wrote:
> (By monotonic time, I presume you mean monotonic real time.) Yes, I
> suppose you could, but I don't think that's terribly useful. I think
> work_time is probably most naturally measured in cpu clock cycles rather
> than an actual time unit. You could convert it to ns, but I don't see
> the point.
>
> I know its a term in general use, but I don't think the term "stolen
> time" is all that useful, particularly when we're talking about a more
> general notion of cpu work contributing to the progress of process
> execution. In the cpufreq case, time isn't "stolen" per se.
How would you deal with something like a pentium 4 HT processor where
you may run slower just because you got scheduled on the sibling of a
cpu that happens to run something else needing the same execution units
you do, causing you to get delayed more, even though the cpu is running
full speed and nothing else is trying to use your "cpu"? I don't think
there is any way to know what the real impact of two processes on a HT
cpu have on each other.
Interesting goal. Not sure it can be done.
--
Len Sorensen
-
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