I'll test (release if > x bytes) tonight//tomorrow.
The main reason why I would prefer adding release_kernel_lock() outside
uaccess.h is the stability:
If we change uaccess.h, then this affects every obscure device driver,
if we change filemap.c & tcp.c, then we achive 90 % if the speed gain
with a far lower change to uncover some rare bugs.
AND: since most obscure device drivers copy only a few bytes,
the compare > 500 is wasted.
OTHO, I wrote a patch which calls 'schedule_timeout()' during
copy_??_user(), and the computer didn't crash immediately, but I
got 1 deadlock after a few minutes.
After I installed a deadlock-detection, the computer was stable...
I'll install that patch again and perform a longer stress test.
> >Could you please forward me the patch vs. 2.2.9?
> Which one? buffer or unlocking?
The unlocking patch. Comparing 2.2.9 & 2.2.9 with a small
modification should provide more accurate benchmarks.
Manfred
-
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/