[lkml]   [1999]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] releasing kernel lock during copy_from/to_user
Andrea Arcangeli wrote:
> If you'll measure something let me know the numbers. Also let me know if
> 500 bytes is too low according to you.
I've measured your original version.
(I sent you that mail a few minutes ago)
500 bytes sounds reasonable.

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.029 / U:0.460 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site