>--> overall we lose.
I know but in general the case where the other CPU grabbed the lock while
we are in copy-user it's the good case.
Think if the other CPU doesn't grab the lock, in such case we only wasted
time releasing the spinlock.
>My current guess:
>- the string routines are to fast--> do not unlock
Ok.
>- clear_page(): 4000-6000 ticks --> unlock
Ok.
>- copy_to/from_user(): release if more than (n) bytes
Ok, my guess -> release if n > 500byte.
>- clear_user(): ??
as copy-user, if size > 500byte.
>- cksum...(): probably, perhaps if more than (x) bytes.
I would use 500byte there too.
If you'll measure something let me know the numbers. Also let me know if
500 bytes is too low according to you.
For the record: the only reason I developed my unlocking code is because I
disagree with code I seen on the list (precisely in emails from Ingo an
ANK) that calls unlock_kernel before copy-user. unlock_kernel() is simply
not robust enough.
>Note: I've read that patches are on the way to Linus for 2.3.3 which
>make the complete page-cache parallel on SMP [from Ingo Molnar].
Yes. But it still make sense to release the kernel lock for the network.
As last thing I see exactly why you all want to call
release_kernel_lock_and_schedule() from tcp.c instead of in
copy_from_user, but I am not going to do that because I don't want to
bloat the soruces with code that will be only a short term measure and
that will have to die ASAP.
I know that calling release_kernel_lock_and_schedule from tcp.c around
cksum and around copy_from_user _only_ in the interesting places would be
the right thing to do, but that's the right thing to do in the _wrong_
approch to the locking problem. That's why I am not doing that.
Spending some minute to add the unlocking code in uaccess.h instead make
some more sense to me since it's trivial, it's robust and it will be
trivial to remove it when we'll not need it anymore (hoepfully tomorrow
:-).
Andrea Arcangeli
-
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/