Messages in this thread | | | Date | Sun, 23 May 1999 23:49:55 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [patch] releasing kernel lock during copy_from/to_user |
| |
On Sun, 23 May 1999, Manfred Spraul wrote:
>1) we should also release the kernel-lock is get_free_pages() >if GFP_WAIT is set for clear_page().
Agreed.
>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)
If another CPU got the lock while we was in copy_from/to_user or in clear page it means that we are been right releasing the lock. The problem according to me is when we release the lock and there wasn't another CPU that will reaquire it fast. If the code that will run is very fast then we'll have less probabilty to scale and we risk to release the kernel lock without really improve the other CPU.
BTW, in general there are only two lock sequence on the bus in the case the spinlock failed the fast path. 1 lock if the spinlock got the fast path.
>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()]
Ah sys_bdflush() doesn't check for need_resched. Really here my sys_bdflush doesn't run in O(N-buffers) but it should stay close to O(1), but better to put a need_resched check in uptime anyway.
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/
| |