Hi Ingo,
On Mon, Apr 5, 2010 at 10:36 PM, Ingo Molnar <mingo@xxxxxxx> wrote:
>> Problem. It appears that these patches have only been sent to linux-mm.
>> Linus doesn't read linux-mm and has never seen them. I do think we should
>> get things squared away with him regarding the overall intent and
>> implementation approach before trying to go further.
>>
>> I forwarded "[PATCH 27 of 41] transparent hugepage core" and his summary was
>> "So I don't hate the patch, but it sure as hell doesn't make me happy
>> either. And if the only advantage is about TLB miss costs, I really don't
>> see the point personally.". So if there's more benefit to the patches than
>> this, that will need some expounding upon.
>>
>> So I'd suggest that you a) address some minor Linus comments which I'll
>> forward separately, b) rework [patch 0/n] to provide a complete description
>> of the benefits and the downsides (if that isn't there already) and c)
>> resend everything, cc'ing Linus and linux-kernel and we'll get it thrashed
>> out.
>>
>> Sorry. Normally I use my own judgement on MM patches, but in this case if I
>> was asked "why did you send all this stuff", I don't believe I personally
>> have strong enough arguments to justify the changes - you're in a better
>> position than I to make that case. Plus this is a *large* patchset, and it
>> plays in an area where Linus is known to have, err, opinions.
>
> Not sure whether it got mentioned but one area where huge pages are rather
> useful are apps/middleware that does some sort of GC with tons of RAM.
Dunno what your measure of "tons of RAM" is but yeah, IIRC when you go
above 2 GB or so, huge pages are usually a big win.
> There the 512x reduction in remapping and TLB flush costs (not just TLB miss
> costs) obviously makes for a big difference not just in straight
> performance/latency but also in cache footprint. AFAIK most GC concepts today
> (that cover many gigabytes of memory) are limited by remap and TLB flush
> performance.
Which remap are you referring to?
AFAIK, most modern GCs split memory in young and old generation
"zones" and _copy_ surviving objects from the former to the latter if
their lifetime exceeds some threshold. The JVM keeps scanning the
smaller young generation very aggressively which causes TLB pressure
and scans the larger old generation less often.
Pekka
--
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