Messages in this thread | | | Date | Sun, 23 May 1999 16:30:52 +0200 | From | Manfred Spraul <> | Subject | kernel_lock() profiling results |
| |
I've written a small patch that measures the duration how long the kernel-lock is owned. The main results: - compiling: * nearly 60% of all callers release the lock after less than 1024 CPU cycles. * a few callers own the lock very long, e.g. sys_bdflush for more than 10 milliseconds (>0.01 seconds). - serving web pages with apache: * only 17% need less than 1024 CPU cycles * 55% need less than 2048 CPU cycles.
The patch and a list of all functions which owned the lock for more then 1.5 milliseconds is at http://www.colorfullife.com/manfreds/kernel_lock/
OTHO, 2048 cpu cycles is about as long as __cpu_user() needs for 700 bytes if source,dest are currently not in the cache (I've tested it with a 16 MB move from user mode). The memmove will be even slower with faster CPU's (i.e. with a higher cpu clock/bus clock multiplier)
My question: Shouldn't we change file_read_actor() [mm/filemap.c, the function which copies data from the page cache to user mode]: we could release the kernel lock if we copy more than 1024 bytes. (we currently do that only if the user mode memory is not paged in.)
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/
| |