Re: removing mm->rss and mm->anon_rss from kernel?

From: Nick Piggin <nickpiggin_at_yahoo.com.au>
Date: 2004-11-09 13:40:20
Christoph Lameter wrote:
> On Mon, 8 Nov 2004, Hugh Dickins wrote:
> 
> 
>>>Maintaining these counters requires locking which interferes with Nick's
>>>and my attempts to parallelize the vm.
>>
>>Aren't you rather overestimating the importance of one single,
>>ideally atomic, increment per page fault?
> 
> 
> We would need to investigate that in detail. What we know is that if
> multiple cpus do atomic increments with an additional spinlock/unlock etc
> as done today then we do have a significant performance impact due to
> exclusive cache lines oscillating between cpus.
> 
> 
>>It's great news if this is really the major scalability issue facing Linux.
> 
> 
> Not sure. This may just be a part of it.
> 

I'm sure it would be a part of it. I think we've basically got 3 things
that share cachelines now, they are the mmap_sem, page_table_lock, and
rss/anon_rss.

After removing the page table lock, it tentatively looks like mmap_sem
is the next largest problem. It may be that the mmap_sem cacheline kind
of serialises threads coming into handle_mm_fault, so the rss doesn't
bounce so much. However I might just try ripping out the rss counters
entirely and just see what happens to performance.


I wonder if a per process flag or something could be used to turn off
the statistics counters? I guess statistics could still be gathered for
that process by using your lazy counting functions, Christoph.
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Mon Nov 8 21:41:34 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:32 EST