lkml.org 
[lkml]   [2006]   [May]   [12]   [last100]   RSS Feed
Views: [more markup]   [less markup]   [headers]   [forward]  
 
 
Messages in this thread
/
DateFri, 12 May 2006 15:17:38 +1000
FromNick Piggin <>
SubjectRe: [PATCH 0/2][RFC] New version of shared page tables
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/

\
 
 \ /
  Last update: 2006-05-12 07:20    [from the cache]
©2003-2008