>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 am using the second patch I posted yesterday (that will apply correctly
to both 2.2.x and 2.3.x) all the time and it's always been rock solid here
under high load, that's why it's just included in the new
2.3.3_andrea3.bz2 :-).
BTW, Ingo do you have a more recent snapshot of your original MMX code in
cksum? If I remeber well you didn't used the lazy-fpu trick to handle the
fpu-state change, and so you was saving/restoring the fpu state every
time. I would like to take a look now if it's possible to use the lazy_fpu
trick to avoid saving/restoring the FPU state every time (the same thing
we do at schedule time).
Comments?
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/