Messages in this thread | | | Date | Wed, 23 Nov 2005 13:36:08 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [patch] SMP alternatives |
| |
On Wed, 23 Nov 2005, Alan Cox wrote: > > There is a much much better way to do it than just user space and > without hitting cr3/cr4 - put "lock works" in the PAT and while we'll > have to add PAT support which we need to do anyway we would get a world > where on uniprocessor lock prefix only works on addresse targets we want > it to - ie pci_alloc_consistent() pages.
No. That would be wrong.
The thing is, "lock" is useless EVEN ON SMP in user space 99% of the time.
Think of all the thread locking in libc - where 99% of all processes are single-threaded, and it does nothing but slow things down.
Actual UP machines are going to go away - even ARM is going SMP, and in the PC space, we'll have multi-core laptops probably being the rule rather than the exception in a couple of years. So the kernel will need "lock" in the forseeable future, and optimizing for UP is a lost game.
But optimizing for a single _thread_ is not a lost game. I don't believe that threaded applications are necessarily going to take over all that much in a lot of areas. Sure, we'll have more threaded apps too, but we'll continue to have tons more of performance-critical non-threaded things like compilers etc.
And _that_ is worth optimizing for. General libraries that have to be able to handle the threaded case dynamically, but that are often run with no shared memory anywhere.
THAT is what I'd like to have CPU support for. Not for UP (it's going away), and not for the kernel (it's never single-threaded).
Linus - 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/
| |