Messages in this thread | | | Date | Sun, 23 May 1999 20:07:50 +0200 | From | Manfred Spraul <> | Subject | Re: [patch] releasing kernel lock during copy_from/to_user |
| |
I've written a small patch that measures how long the kernel lock is usually locked. (see http://www.colorfullife.com/manfreds/kernel_lock) I haven't yet measured your patches. For a stock kernel: compiling: ~ 60 % own it for < 1024 instructions apache: ~ 55 % own it for < 2048 instructions
1) we should also release the kernel-lock is get_free_pages() if GFP_WAIT is set for clear_page(). On an PII-350, the clear_page() takes 4600-6000 cpu ticks, that's enough for most kernel_lock-users.
2) you should also take into account the costs associated with unlock_kernel()// lock_kernel(): - if no other CPU gets the lock, I guess around 20 ticks - if another CPU gets the lock, the the cost is higher (cache-line contention, LOCK cycles) - unless we don't need the kernel-lock for a long time, (i.d say more than 1000 CPU-ticks), we win nothing: one CPU is running, another is spinning. unlock()//lock() just switches the roles.
3) the current worst cast is 4 Million instructions or 11 milliseconds, i.e. changes are nessecary for performance. [sys_bdflush(), not far behind: sys_read(), sys_write()]
Therefore, I'd suggest: - do not change uaccess, but search for all users which sometimes copy more then 1024 bytes memory, and _if_ they move more than 1024 bytes memory, then they release the kernel lock. The number 1024 is guessed, perhaps 512 or 384 are better. (the number is probably architecture specific, not every architecture has such a slow memory bus)
Regards, 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/
| |