Date:	Sun, 08 Apr 2007 13:04:47 -0400
From:	Gene Heskett <gene.heskett@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	Ingo Molnar <mingo@...e.hu>, Con Kolivas <kernel@...ivas.org>,
	Mike Galbraith <efault@....de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	ck list <ck@....kolivas.org>
Subject: Re: Ten percent test

On Sunday 08 April 2007, Ingo Molnar wrote:
>* Ingo Molnar <mingo@...e.hu> wrote:
>> > My question then, is why did it take a very public cat-fight to get
>> > this looked at and the code adjusted?  Its been what, nearly 2 years
>> > since Linus himself made a comment that this thing needed fixed.
>> > The fixes then done were of very little actual effectiveness and the
>> > situation then has gradually deteriorated since.
>>
>> this is pretty hard to get right, and the most objective way to change
>> it is to do it testcase-driven. FYI, interactivity tweaking has been
>> gradual, the last bigger round of interactivity changes were done a
>> year ago:
>
>and note that a year ago Mike did a larger patch too, not unlike his
>current patch - but we hoped that his smaller change would be sufficient
>- and nobody came along and said "i tested Mike's and the difference is
>significant on my system".

May I suggest that while it may have been noticeable, it was 
not 'significant', so we didn't sing praises and bow to mecca at the 
time.  I just thought that this is the way it was, till Cons patch proved 
otherwise for this  'desktop' user.  We were then, and still are, looking 
for the magic that lets it all load up and slow down in a linear feeling 
fashion.  Only those IRQ's that are fleeting and need serviced NOW should 
be exceptions to that rule.  AFAIAC, gzip can take its turn in the queue, 
getting no more time in proportion than any other process that wakes up 
in its slice and finds it has something to do, if nothing to do it should 
yield the floor immediately, and in any event be put back at the far end 
of the queue when its timeslice is over.  gzip in particular seems very 
reticent to give up the cpu at what should be the end of its timeslice.  
As it is, the IRQ's are being serviced, so no keystrokes are being lost, 
or very few, unlike the situation 2 years ago when whole sentences typed 
blind were on the missing list when x finally did get a chance to play 
catchup.

As a desktop user, I fail to understand any good reason why a keystroke 
typed can't be echoed to the screen within 200 milliseconds regardless of 
how many gzip -best's amdump may be running in the background.

I have a coco3, running nitros9 at a cpu clock rate of 1.79mhz with a 
1/10th second context switch, in the basement that CAN do that while 
assembling an executable with a separate process printing the listing of 
that assembly as it progresses.

Why can't linux?

>Which seems to suggest that the number of 
>problem-systems and worried users/developers isnt particularly large.

Again, may I suggest that this sort of behavior on the desktop is a 
contributing factor to that relative scarcity?

>	Ingo



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The meek will inherit the earth -- if that's OK with you.
-
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