Re: Transparent Hugepage Support #30

[Balbir Singh]

* Andrea Arcangeli <aarcange@xxxxxxxxxx> [2010-09-10 01:40:08]:

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

OK, when the code is touched next and from now on, we'll stop making
that assumption.

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

Thanks, is there an overhead of the compound_lock that will show up?

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

Please do look at it, most of the churn is not controllable since it
is bug fixes and feature enhancements for newer subsystems and
performance. We'll try not to break anything fundamental.


-- 
	Three Cheers,
	Balbir
--
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/