Re: smp race fix between invalidate_inode_pages* and do_no_page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Andrew Morton wrote:
Nick Piggin <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux