lkml.org 
[lkml]   [2006]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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    [W:0.112 / U:1.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site