Messages in this thread | | | Date | Fri, 21 May 1999 21:01:55 +0200 | From | Andi Kleen <> | Subject | Re: Bad apache perfomance wtih linux SMP |
| |
On Fri, May 21, 1999 at 03:29:14PM +0200, Andrea Arcangeli wrote: > On Wed, 19 May 1999, Andi Kleen wrote: > > >BTW the modification only covers the TCP send path, there is a more > >extensive patch around that does it for ext2 reading, writing, TCP > >receiving and other parts too - the basic principle is always the same. > > If you look at my patch (the second one, in the first one I missed the > reaquire_kernel_lock done before returning from schedule, woops :) then > you'll see my approch to address the unlock-during-uaccess. My patch don't > change tcp/ip ext2 etc... but it touch only uaccess.h and usercopy.c. I > don't like to put unlock_kernel all over the place. Also considering that > an unlock_kernel() is not assured to drop the kernel lock for real. It can > now, but if for some reason tomorrow I'll call the same function with > lock_depth == 1, then the unlock_kernel you added will be a no-op.
I don't think it is a good idea to always call the unlock - 90+ of all *_user's in the kernel are not performance critical at all (in setup only functions), but the call is still inlined, so it is just unnecessary code bloat.
Also the unlock_kernel thing is not the right 2.3 fix - there the code should be fixed to have fine grained locks - but just a bandaid to fix the worst scaling problems in 2.2 with minimal changes.
[ Small data point:
% fred:/usr/src/linux% find -type f | xargs cat | grep 'copy.*user' | wc -l 2724
Assuming about 1000 of them are used in a realistic configuration, and you only added 20 bytes to each of them that is already 2K for not much gain. Then 2K and 4K there and someday you have a bloated monster. Please think twice before adding anything to a commonly used inline function.]
-Andi
-- This is like TV. I don't like TV.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |