On 04/12/2010 04:30 PM, Andrea Arcangeli wrote:
On Mon, Apr 12, 2010 at 04:22:30AM -0700, Arjan van de Ven wrote:
Now hugepages have some interesting other advantages, namely they save
pagetable memory..which for something like TPC-C on a fork based
database can be a measureable win.
It doesn't save pagetable memory (as in `grep MemFree
/proc/meminfo`).
So where does the pagetable go?
To achive that we'd need to return -ENOMEM from
split_huge_page_pmd and split_huge_page, which would complicate things
significantly. I'd prefer if we could get rid gradually of
split_huge_page_pmd calls instead of having to handle a retval in
several inner nested functions that don't contemplate returning error
like all their callers.
I think the saving in pagetables isn't really interesting... it's a
couple of gigabytes but it doesn't move the needle as much as being
able to boost CPU performance.
Fork-based (or process+shm based, like Oracle) replicate the page tables
per process, so it's N * 0.2%, which would be quite large. We could
share pmds for large shared memory areas, but it wouldn't be easy.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>