Re: [PATCH 00 of 41] Transparent Hugepage Support #17

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

 



On 04/06/2010 04:45 PM, Nick Piggin wrote:

  I don't see how
hardware improvements can drastically change the numbers above, it's
clear that for the 4k case the host takes a cache miss for the pte,
and twice for the 4k/4k guest case.
It's because you're missing the point. You're taking the most
unrealistic and pessimal cases and then showing that it has fundamental
problems. Speedups like Linus is talking about would refer to ways to
speed up actual workloads, not ways to avoid fundamental limitations.

Prefetching, memory parallelism, caches. It's worked for 25 years :)

btw, a workload that's known to benefit greatly from large pages is the kernel itself. It's very pointer-chasey and has a large working set (the whole of memory, in fact). But once you run it in a guest you've turned it into the 2M/4k case in the table which is basically a slightly slower version of host 4k pages.

So, if we want good support for kernel intensive workloads in guests, or kernel-like workloads in the host (or kernel-like workloads in guest userspace), then we need good large page support.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]