Re: [PATCH 0/2][RFC] New version of shared page tables

[Nick Piggin <nickpiggin@yahoo.com.au>]

Brian Twichell wrote:
> Nick Piggin wrote:

> > Of course if it was free performance then we'd want it. The downsides 
> > are that it
> > is a significant complexity for a pretty small (3%) performance gain 
> > for your apparent
> > target workload, which is pretty uncommon among all Linux users.
>
>
> Our performance data demonstrated that the potential gain for the 
> non-hugepage case is much higher than 3%.

The point is, there are hugepages. They were a significant additional
complexity but the concession was made because they did provide a
large speedup for databases.

> > Ignoring the complexity, it is still not free. Sharing data across 
> > processes adds to
> > synchronisation overhead and hurts scalability. Some of these page 
> > fault scalability
> > scenarios have shown to be important enough that we have introduced 
> > complexity _there_.
>
>
> True, but this needs to be balanced against the fact that pagetable 
> sharing will reduce the number of page faults when it is achieved.  
> Let's say you have N processes which touch all the pages in an M page 
> shared memory region.  Without shared pagetables this requires N*M page 
> faults; if pagetable sharing is achieved, only M pagefaults are required.
>
> > And it seems customers running "out-of-the-box" settings really want 
> > to start using
> > hugepages if they're interested in getting the most performance 
> > possible, no?
>
>
> My perspective is that, once the customer is required to invoke "echo 
> XXX > /proc/sys/vm/nr_hugepages" they've left the "out-of-the-box" 
> domain, and entered the domain of hoping that the number of hugepages is 
> sufficient, because if it's not, they'll probably need to reboot, which 
> can be pretty inconvenient for a production transaction-processing 
> application.

I think it is pretty easy to reserve hugepages at bootup. This is what
a production transaction processing system will be doing, won't it?
Especially if they're performance constrained and hugepages gives them
a 30% performance boost.

--
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/