Re: [PATCH 00 of 67] Transparent Hugepage Support #18

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

 



On 04/09/2010 06:50 PM, Andrea Arcangeli wrote:

ok, #19 is a different story.  A 1.2GB sort vs 'make -j12' and a cat of
the source tree and some light swapping, all in 2GB RAM, didn't quite
reach 1.2GB but came fairly close.  The sort was started while memory
was quite low so it had to fight its way up, but even then khugepaged
took less that 1.5 seconds total time after a _very_ long compile.
Good. Also please check you're on
8707120d97e7052ffb45f9879efce8e7bd361711, with that one all bugs are
ironed out, it's stable on all my systems under constant mixed heavy
load (the same load would crash it in 1 hour with the memory
compaction bug, or half a day with the anon-vma bugs and no memory
compaction). 8707120d97e7052ffb45f9879efce8e7bd361711 is rock solid as
far as I can tell.

Yes, that's what I used.

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

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