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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
