lkml.org 
[lkml]   [2006]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: smp race fix between invalidate_inode_pages* and do_no_page
Andrew Morton wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
>>(I guess reclaim might be one, but quite rare -- any other significant
>> lock_page users that we might hit?)
>
>
> The only time 2.6 holds lock_page() for a significant duration is when
> bringing the page uptodate with readpage or memset.
>

Yes that's what I thought. And we don't really need to worry about this
case because filemap_nopage has to deal with it anyway (ie. we shouldn't
see a locked !uptodate page in do_no_page).

> The scalability risk here is 100 CPUs all faulting in the same file in the
> same pattern. Like the workload which caused the page_table_lock splitup
> (that was with anon pages). All the CPUs could pretty easily get into sync
> and start arguing over every single page's lock.
>

Yes, but in that case they're still going to hit the tree_lock anyway, and
if they do have a chance of synching up, the cacheline bouncing from count
and mapcount accounting is almost as likely to cause it as the lock_page
itself.

I did a nopage microbenchmark like you describe a while back. IIRC single
threaded is 2.5 times *more* throughput than 64 CPUs, even when those 64 are
faulting their own NUMA memory (and obviously different pages). Thanks to
tree_lock.

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com

-
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: 2006-01-13 11:40    [W:0.094 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site