Messages in this thread | | | Date | Fri, 13 Jan 2006 21:37:39 +1100 | From | Nick Piggin <> | Subject | Re: 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/
| |