On Sunday 08 April 2007, Ingo Molnar wrote:
>* Ingo Molnar <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
