> The akpm patch is achieving a MUCH better latency than pure -preempt,
Can you please point us at the benchmark results that support your claim?
> and only has 40
> or so coded preemption points instead of a few hundred (eg every
> spin_unlock)....
So? The cost of this is, in theory, a dec and a branch normally not taken.
Robert hasn't coded it that way in the current incarnation, and personally,
I'd rather see the correctness proven before the microoptimizations are
done, but that's where it's going in theory. Big deal.
On the other hand, I just did a test for myself that pretty well makes up
my mind about this patch. I'm typing this right now on a 64 Meg laptop with
a slow disk, dma turned off. On this machine, debian apt-get dist-upgrade
is essentially a DoS - once it gets to unpacking packages and configuring,
for whatever reason, the machine becomes almost ununsable. Changing windows
for example, can take 10-15 seconds. Updatedb, while not quite as bad, is
definitely an irritant as far as interactive use goes.
With Robert's patch, the machine is a little sluggish during apt-get, but
quite usable. This is a *huge* difference. And during updatedb, well, I
hardly notice it's happening, except for the disk light.
So I like this patch. What was your complaint again? If you've got hard
numbers and repeatable benchmarks, please trot them out.
-- Daniel - 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/