Messages in this thread | | | Date | Fri, 30 Dec 2005 13:05:11 +1100 | From | Nick Piggin <> | Subject | Re: [patch 1/3] mutex subsystem: trylock |
| |
Nicolas Pitre wrote:
> I provided you with the demonstration last week: >
I didn't really find it convincing.
> - the non SMP (ARM version < 6) is using xchg. > > - xchg on ARM version < 6 is always faster and smaller than any > preemption disable. >
Maybe true, but as I said, if you have preemption enabled, then there are far more preempt_xxx operations in other places than semaphores, which impact both size and speed.
> - xchg on ARM is the same size as the smallest solution you may think of > when preemption is disabled and never slower (prove me otherwise? if > you wish). >
I was going from your numbers where you said it was IIRC a cycle faster.
> - all xchg based primitives are "generic" code already. >
And yet there is a need for architecture specific code. Also having xchg and a cmpxchg variants mean that you have two different sets of possible interleavings of instructions, and xchg has much more subtle cases as you demonstrated.
> And I think you didn't look at the overall patch set before talking > about "lots of ugliness", did you? The fact is that the code,
Yes I did and I think it is more ugly than my proposal would be.
> especially the core code, is much cleaner now than it was when > everything was seemingly "generic" since the current work on > architecture abstractions still allows optimizations in a way that is so > much cleaner and controlled than what happened with the semaphore code, > and the debugging code can even take advantage of it without polluting > the core code. > > It happens that i386, x86_64 and ARM (if v6 or above) currently have > their own tweaks to save space and/or cycles in a pretty strictly > defined way. The effort is currently spent on making sure if other > architectures want to use one of their own tricks for those they can do > it without affecting the core code which remains 95% of the whole thing > (which is not the case for semaphores), and the currently provided > architecture specific versions are _never_ bigger nor slower than any > generic version would be. Otherwise what would be the point? >
I don't think size is a great argument, because the operations should be out of line anyway to save icache (your numbers showed a pretty large increase when they're inlined)
And as for speed, I'm not arguing that you can't save a couple of cycles, but I'm weighing that against the maintainability of a generic implementation which has definite advantages. Wheras I don't think you could demonstrate any real speed improvement for saving a few cycles from slightly faster semaphore operations on CONFIG_PREEMPT kernels?
If someone ever did find the need for an arch specific variant that really offers advantages, then there is nothing to stop tha being added.
-- SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.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/
| |