* Gavin Sherry ([EMAIL PROTECTED]) 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
signature.asc
Description: Digital signature