>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/