Re: Bad apache perfomance wtih linux SMP

Andi Kleen (ak@muc.de)
Fri, 21 May 1999 21:01:55 +0200

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/