Well to start with:
1) Maybe I should be more precise: The latency measures I've seen
posted all favor Morton and not preempt. Since the claimed purpose
of both patches is improving latency isn't that more interesting
than measuremts of kernel compile?
2) In these measurements
the tree is different each time so the measurement doesn't
seem very stable. It's not exactly a secret that file layout
can have an affect on performance.
3) There is no measure of preempt without Ingo's scheduler
4) this is what I want to see:
Run the periodic SCHED_FIFO task I've posted multiple times
Let's see worst case error
Let's see effect on the background kernel compile
All the rest is just so much talk about "interactive feel". I saw
exactly the same claims from the people who wanted kernel graphics.
On Sun, Jan 13, 2002 at 01:22:57PM -0500, Robert Love wrote:
> On Sun, 2002-01-13 at 12:42, jogi@planetzork.ping.de wrote:
>
> > 13-pre5aa1 18-pre2aa2 18-pre3 18-pre3s 18-pre3sp 18-pre3minill
> > j100: 6:59.79 78% 7:07.62 76% * 6:39.55 81% 6:24.79 83% *
> > j100: 7:03.39 77% 8:10.04 66% * 8:07.13 66% 6:21.23 83% *
> > j100: 6:40.40 81% 7:43.15 70% * 6:37.46 81% 6:03.68 87% *
> > j100: 7:45.12 70% 7:11.59 75% * 7:14.46 74% 6:06.98 87% *
> > j100: 6:56.71 79% 7:36.12 71% * 6:26.59 83% 6:11.30 86% *
> >
> > j75: 6:22.33 85% 6:42.50 81% 6:48.83 80% 6:01.61 89% 5:42.66 93% 7:07.56 77%
> > j75: 6:41.47 81% 7:19.79 74% 6:49.43 79% 5:59.82 89% 6:00.83 88% 7:17.15 74%
> > j75: 6:10.32 88% 6:44.98 80% 7:01.01 77% 6:02.99 88% 5:48.00 91% 6:47.48 80%
> > j75: 6:28.55 84% 6:44.21 80% 9:33.78 57% 6:19.83 85% 5:49.07 91% 6:34.02 83%
> > j75: 6:17.15 86% 6:46.58 80% 7:24.52 73% 6:23.50 84% 5:58.06 88% 7:01.39 77%
>
> Again, preempt seems to reign supreme. Where is all the information
> correlating preempt is inferior? To be fair, however, we should bench a
> mini-ll+s test.
>
> But I stand by my original point that none of this matters all too
> much. A preemptive kernel will allow for future latency reduction
> _without_ using explicit scheduling points everywhere there is a
> problem. This means we can tackle the problem and not provide a million
> bandaids.
>
> Robert Love
-- --------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com- 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/
This archive was generated by hypermail 2b29 : Tue Jan 15 2002 - 21:00:42 EST