Re: interactive task starvation
- From: Willy Tarreau <willy@xxxxxxxxx>
- Date: Tue, 21 Mar 2006 20:32:16 +0100
On Tue, Mar 21, 2006 at 07:39:11PM +0100, Rafael J. Wysocki wrote:
On Tuesday 21 March 2006 15:39, Willy Tarreau wrote:
On Wed, Mar 22, 2006 at 01:19:49AM +1100, Con Kolivas wrote:
On Wednesday 22 March 2006 01:17, Mike Galbraith wrote:
On Wed, 2006-03-22 at 00:53 +1100, Con Kolivas wrote:
The yardstick for changes is now the speed of 'ls' scrolling in the
console. Where exactly are those extra cycles going I wonder? Do you
think the scheduler somehow makes the cpu idle doing nothing in that
timespace? Clearly that's not true, and userspace is making something
spin unnecessarily, but we're gonna fix that by modifying the
scheduler.... sigh
*Blink*
Are you having a bad hair day??
My hair is approximately 3mm long so it's kinda hard for that to happen.
What you're fixing with unfairness is worth pursuing. The 'ls' issue just
blows my mind though for reasons I've just said. Where are the magic cycles
going when nothing else is running that make it take ten times longer?
Con, those cycles are not "magic", if you look at the numbers, the time is
not spent in the process itself. From what has been observed since the
beginning, it is spent :
- in other processes which are starvating the CPU (eg: X11 when xterm
scrolls)
- in context switches when you have a pipe somewhere and the CPU is
bouncing between tasks.
Concerning your angriness about me being OK with (0,0) and still
asking for tunables, it's precisely because I know that *my* workload
is not everyone else's, and I don't want to conclude too quickly that
there are only two types of workloads.
Well, perhaps we can assume there are only two types of workloads and
wait for a test case that will show the assumption is wrong?
It would certainly fit most usages, but as soon as we find another group
of users complaining, we will add another sysctl just for them ? Perhaps
we could just resume the two current sysctls into one called
"interactivity_boost" with a value between 0 and 100, with the ability
for any user to increase or decrease it easily ? Mainline would be
pre-configured with something reasonable, like what Mike proposed as
default values for example, and server admins would only set it to
zero while desktop-intensive users could increase it a bit if they like
to.
Maybe you're right, maybe you're wrong. At least you're right for as long
as no other workload has been identified. But thinking like this is like
some time ago when we thought that "if it runs XMMS without skipping,
it'll be OK for everyone".
However, we should not try to anticipate every possible kind of workload
IMHO.
I generally agree on this, except that we got caught once in this area for
this exact reason.
Greetings,
Rafael
Regards,
Willy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: interactive task starvation
- From: Rafael J. Wysocki
- Re: interactive task starvation
- References:
- interactive task starvation
- From: Mike Galbraith
- Re: interactive task starvation
- From: Con Kolivas
- Re: interactive task starvation
- From: Willy Tarreau
- Re: interactive task starvation
- From: Rafael J. Wysocki
- interactive task starvation
- Prev by Date: Re: Some sata_mv error messages
- Next by Date: Re: Some sata_mv error messages
- Previous by thread: Re: interactive task starvation
- Next by thread: Re: interactive task starvation
- Index(es):
Relevant Pages
|
