Re: [PATCH 01 of 66] disable lumpy when compaction is enabled

[Andrea Arcangeli]

On Wed, Nov 10, 2010 at 02:27:04PM +0000, Mel Gorman wrote:
> Agreed. Any performance increase from THP is not likely to offset the
> cost of lumpy reclaim.

Exactly. Furthermore the improvement will still happen later by
polling compaction once every 10 sec with khugepaged (this is also
required in case some other guest or application quit releasing tons
of ram maybe natively order 9 in the buddy without requiring any
further compaction invocation).

What the default should be I don't know, but I like a default that
fails without causing swap storms. If you want the swap storms and to
drop all ptes regardless of their young bits, you should ask
explicitly for it I think. Anybody asking for high order allocation
and pretending to succeed despite the anti-frag and movable pageblocks
migrated with compaction aren't enough to succeed should be able to
handle a full graceful failure like THP does by design (or worst case
to return error to userland). As far as I can tell tg3 atomic order 2
allocation also provides for a graceful fallback for the same reason
(however in new mainline it floods the dmesg with tons of printk,
which it didn't used to with older kernels but it's not an actual
regression).

> Again agreed, I have no problem with lumpy reclaim being pushed aside.
> I'm just less keen on it being disabled altogether. I have high hopes
> for the series I'm working on that it can be extended slightly to suit
> the needs of THP.

Great. Well this is also why I disabled it with the smallest possible
modification, to avoid stepping on your toes.

> Nah, the first thing I did was eliminate being "my fault" :). It would
> have surprised me because the patches in isolation worked fine. It
> thought the inode changes might have had something to do with it so I
> was chasing blind alleys for a while. Hopefully d065bd81 will prove to
> be the real problem.

Well I wasn't sure if you tested it already on that very workload, the
patches weren't from you (even if you were in the signoffs). I
mentioned it just in case, glad it's not related :).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/