Re: page fault scalability patch V11 [0/7]: overview

From: Nick Piggin <nickpiggin_at_yahoo.com.au>
Date: 2004-11-20 12:45:59
Christoph Lameter wrote:
> On Sat, 20 Nov 2004, Nick Piggin wrote:
> 
> 
>>I think this sounds like it might be a good idea. I prefer it to having
>>the unbounded error of sloppy rss (as improbable as it may be in practice).
> 
> 
> It may also be faster since the processors can have exclusive cache lines.
> 

Yep.

> This means we need to move rss into the task struct. But how does one get
> from mm struct to task struct? current is likely available most of
> the time. Is that always the case?
> 

It is available everywhere that mm_struct is, I guess. So yes, I
think `current` should be OK.

> 
>>The per thread rss may wrap (maybe not 64-bit counters), but even so,
>>the summation over all threads should still end up being correct I
>>think.
> 
> 
> Note though that the mmap_sem is no protection. It is a read lock and may
> be held by multiple processes while incrementing and decrementing rss.
> This is likely reducing the number of collisions significantly but it wont
> be a  guarantee like locking or atomic ops.
> 

Yeah the read lock won't do anything to serialise it. I think what Linus
is saying is that we _don't care_ most of the time (because the error will
be bounded). But if it happened that we really do care anywhere, then the
write lock should be sufficient.
-
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 Fri Nov 19 20:56:32 2004

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