lkml.org 
[lkml]   [1999]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectkernel_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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.050 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site