Andrea Arcangeli <[email protected]> wrote:
>
> On Wed, Jan 11, 2006 at 03:08:31PM +1100, Nick Piggin wrote:
> > I'd be inclined to think a lock_page is not a big SMP scalability
> > problem because the struct page's cacheline(s) will be written to
> > several times in the process of refcounting anyway. Such a workload
> > would also be running into tree_lock as well.
>
> I seem to recall you wanted to make the tree_lock a readonly lock for
> readers for the exact same scalability reason? do_no_page is quite a
> fast path for the tree lock too. But I totally agree the unavoidable is
> the atomic_inc though, good point, so it worth more to remove the
> tree_lock than to remove the page lock, the tree_lock can be avoided the
> atomic_inc on page->_count not.
>
> The other bonus that makes this attractive is that then we can drop the
> *whole* vm_truncate_count mess... vm_truncate_count and
> inode->trunate_count exists for the only single reason that do_no_page
> must not map into the pte a page that is under truncation.
I think you'll find this hard - filemap_nopage() is the first to find the
page but we need lock coverage up in do_no_page(). So the ->nopage
protocol will need to be changed to "must return with the page locked". Or
we add a new ->nopage_locked and call that if the vm_ops implements it.
But I agree it's a good change if we can pull it off.
-
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]
