Skip to contentSkip to conversation

kernel_lock() profiling results

DISCUSSION Manfred Spraul 3 participants 5 messages May 23, 1999 – May 29, 1999 Memory management

lore
Share & tools
lore

Manfred Spraul

author
#0 lore raw

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, send a message with 'unsubscribe linux-mm my@address' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

#1 lore raw

Hi,

Quoted 4 lines · Manfred Spraul

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.)

ftp://ftp.uk.linux.org/pub/linux/sct/performance

contains a patch Dave Miller and I put together to drop the kernel lock during a number of key user mode copies.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

author
#2 lore raw
Quoted 4 lines · Stephen C. Tweedie

ftp://ftp.uk.linux.org/pub/linux/sct/performance

contains a patch Dave Miller and I put together to drop the kernel lock during a number of key user mode copies.

1) Andrea noticed that 'unlock_kernel()' only releases the kernel lock if the lock was obtained once.
He added two new functions: one stores the current lock depth, releases the lock and sets current->lock_depth =-1.
The other reverses that.

I think we need these functions:
* it's save to call the functions without the kernel_lock held.
* the unlock is effective for recursive calls.

2) Here's a excerpt from an email I wrote a few days ago:

Quoted 15 lines

I've modified uaccess.h, and I have now a list of all functions which called copy_to/from_user() for more than 512 bytes (apache, make clean; make fs; find /usr/bin)

* read_file_actor()
* ext2_file_write()
* block_read()
* copy_mount_options() << really rare
* proc_file_read() << rare??
* pipe_write()
* pipe_read()
* 2*vt_ioctl() << could be remote gdb.
* tcp_do_sendmsg()
* copy_strings() << only during fork()?

Quoted 9 lines

Additionally, the following functions could also release the kernel lock:
* padzero() in binfmt_elf:
This function clears up to 4096 bytes user memory. The average should be 2048.
* update_vm_mapping():
the function can wait in wait_on_page(), we should break nothing
* get_free_page():
if GFP_WAIT, for memset(,0,PAGE_SIZE)

I didn't use NFS, knfsd, other fs except ext2.

--
Manfred
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

#3 lore raw

Hi,

Quoted 2 lines · Manfred Spraul

1) Andrea noticed that 'unlock_kernel()' only releases the kernel lock if the lock was obtained once.

Yes, but in all the places we are currently doing the copy_*_user, we only hold the lock once. In general we might want to do a true save/restore of lock_depth for a new, self-unlocking copy_*_user, but right now the droplock diffs still do the right thing the simple way.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

#4 lore raw
Quoted 2 lines · Stephen C. Tweedie

save/restore of lock_depth for a new, self-unlocking copy_*_user, but right now the droplock diffs still do the right thing the simple way.

I wouldn't call it the "right thing". It's also not simpler according to me since to make sure that the unlock_kernel is really dropping the kernel_flag spinlock you must check all entry paths and verify that lock_depth is 0 at such time.

Andrea Arcangeli

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address' in the body to [email protected]. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/