* Gavin Sherry (swm@linuxworld.com.au) wrote:
> It does make it painful for distribution/package maintainers but I think
> the potential benefits for single/multi-CPU architectures are high. It
> means that our lock intrinsic on uniprocessors can just be a lock/delay
> loop without any spinning -- which is a complete waste of time if you only
> have one CPU.
>
> Doing this at runtime involvevs some pretty significant uglification of
> low level code I think.
I suspect distributors would go for the multi-cpu setup (especially if
a uniprocessor build is *broken* for multiprocessor) and then in a
lot of cases you end up not actually getting any benefit. I'm afraid
you'd also end up having to tell alot of people who complain to
recompile, who will then complain back to their distributors, etc.
I suppose another option would be to provide seperate packages... Could
this be done as a shared library so it's more 'plug-and-play' to switch
between the two? I dunno, just trying to think about how to deal with
this without making it suck terribly bad for me (as a Debian user and
maintainer).
Certainly makes me wish there was a way to do it which made the kernel
handle the uniprocessor/multiprocessor question and did locking as
appropriate for those. Ah, well.
Thanks,
Stephen
