Thread (5 messages) 5 messages, 3 authors, 2004-07-27

Re: [PATCH] Locking optimization for cache_reap

From: Dimitri Sivanich <hidden>
Date: 2004-07-27 02:01:43
Also in: lkml

On Mon, Jul 26, 2004 at 08:47:57PM -0500, Dimitri Sivanich wrote:
While you've got irq's disabled, drain_array() (the function my patch removes)
acquires the cache spin_lock, then releases it.  Cache_reap then acquires
it again (with irq's having been off the entire time).  My testing has found
that simply acquiring the lock once while irq's are off results in fewer
excessively long latencies.

Results probably vary somewhat depending on the circumstance.
Of course, I should add that all of this is from the perspective of the
cpu doing the cache_reap.  If others feel that this may add too much
latency to other paths, other solutions may be in order.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help