Messages in this thread |  | | Date | Tue, 10 Jun 2003 12:11:47 -0700 | From | William Lee Irwin III <> | Subject | Re: 2.5.70-mm6 |
| |
At 04:41 AM 6/10/2003 -0700, William Lee Irwin III wrote: >> \vomit{Next you'll be telling me worse is better.}
On Tue, Jun 10, 2003 at 08:53:51PM +0200, Mike Galbraith wrote: > That's an unearned criticism. > Timeslice management is currently an approximation. IFF the approximation > is good enough, it will/must out perform pedantic bean-counting. Current > timeslice management apparently isn't quite good enough, so I'm trying to > find a way to increase it's informational content without the (in general > case useless) overhead of attempted perfection. I'm failing miserably btw > ;-)
The criticism was of the maxim invoked, not the specific direction you're hacking in.
At 04:41 AM 6/10/2003 -0700, William Lee Irwin III wrote: >> The issue is the driver returning garbage; not having as good of >> precision from hardware is no fault of the method. I'd say timer_pit >> should just return jiffies converted to nanoseconds.
On Tue, Jun 10, 2003 at 08:53:51PM +0200, Mike Galbraith wrote: > That's the option that I figured was April 1 material, because of the > missing precision. If it could be made (somehow that I don't understand) > to produce a reasonable approximation of a high resolution clock, sure.
If there's a TSC, it can be used for extra interpolation. But I think timer_tsc already does that. I don't think it's quite so laughable; the machines missing reliable time sources are truly crippled in some way, by obsolescence or misdesign. I wouldn't call this a deficit. The major platforms will do fine, and the rest will do no worse than now apart from perhaps some function call and arithmetic overhead.
At 04:41 AM 6/10/2003 -0700, William Lee Irwin III wrote: >> Also, I posted the "thud" fix earlier in this thread in addition to the >> monotonic_clock() bits. AFAICT it mitigates (or perhaps even fixes) an >> infinite priority escalation scenario.
On Tue, Jun 10, 2003 at 08:53:51PM +0200, Mike Galbraith wrote: > (yes, mitigates... maybe cures with round down, not really sure) > Couple that change with reintroduction of backboost to offset some of it's > other effects and a serious reduction of CHILD_PENALTY and you'll have a > very snappy desktop. However, there is another side of the > equation. Large instantaneous variance in sleep_avg/prio also enables the > scheduler to react quickly such that tasks which were delayed for whatever > reason rapidly get a chance collect their ticks and catch up. It can and > does cause perceived unfairness... which is in reality quite fair. It's > horrible for short period concurrency, but great for long period > throughput. AFAIKT, it's a hard problem.
I don't know that there are answers better than mitigation.
I propose we err on the other side of the fence and back off as cases where the larger instantaneous variances are more clearly needed arise.
-- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |