Re: Transparent Hugepage Support #30

From: Andrea Arcangeli
Date: Thu Sep 09 2010 - 19:42:42 EST


Hello,

On Thu, Sep 09, 2010 at 04:16:30PM +0530, Balbir Singh wrote:
> * Andrea Arcangeli <aarcange@xxxxxxxxxx> [2010-09-01 21:08:59]:
> > btw, memcg developers could already support THP inside memcg even if
> > THP is not included yet without any sort of problem, so it's also
>
> Could you elaborate by what you mean here?

Ok, what I mean is that you could already stop assuming the "page"
passed as parameter to memcg is PAGE_SIZE in size. It would still work
fine. The check should later be done with PageTransCompound as that
will be optimized away at compile time when
CONFIG_TRANSPARENT_HUGEPAGE=n. But in the meantime PageCompund shall
work fine.

One nasty detail to pay attention to later (which isn't possible to
implement until compound_lock is defined), is that at times we may
also need to take the compound_lock to avoid the size of the page to
change from under us (it should only be needed if PageTransCompound
returns true so it won't affect the regular paths and it won't be
built if THP is off at compile time). The collapsing takes the
mmap_sem write mode which normally won't risk to run in parallel,
furthermore the collapsing isn't done in place so it's unlikely to
give issues. So only the transition from transcompound to regular
page, is likely to require special care.

> We try not to change too drastically, but several of the current
> changes are fixes, we are currently contemplating some more changes to
> support the I/O control. Some of the recent changes have been driven
> by tracing. We will pay closer attention to THP changes, thanks for
> bring your concern to our notice.

Thanks a lot. I can already start looking more closely into the memcg
of current upstream myself, if this is a good time and there are no
more big changes planned or already queued in some git tree waiting to
be pulled.
--
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/