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/