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

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

 



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