lkml.org 
[lkml]   [2002]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] breaking up the pagemap_lru_lock in rmap
On Mon, Mar 04, 2002 at 10:04:51AM -0800, Martin J. Bligh wrote:
> High contention on the pagemap_lru lock seems to be a major
> scalability problem for rmap at the moment. Based on wli's and
> Rik's suggestions, I've made a first cut at a patch to split up the
> lock into a per-page lock for each pte_chain.

some year ago when I put a spinlock in the page structure I was flamed :)
That was fair enough. Sometime the theorical maximum degree of
scalability doesn't worth the additional ram usage.

but anyways, can you show where do you see this high contenction on the
pagemap_lru lock? Maybe that's more a sympthom that the rmap is doing
something silly with the lock acquired, can you measure high contention
also on my tree on similar workloads? I think we should worry about the
pagecache_lock, before the pagemap_lru lock. During heavy paging
activity, the system should become I/O bound, and the spinlock there
shouldn't matter. while when the system time goes up, it usually doesn't
run inside the vm, but it usually runs cached and there the
pagecache_lock matters.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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