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

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

 



* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> 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.

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.

So if we accept that shuffling lots of virtual memory is worth doing then the 
next natural step would be to make it transparent.

Just my 2c,

	Ingo

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