Re: Transparent Hugepage Support #33

[Andrea Arcangeli]

Hi Daisuke and Kame,

On Thu, Dec 16, 2010 at 10:10:53AM +0900, Daisuke Nishimura wrote:
> Hi,
> 
> On Thu, 16 Dec 2010 09:54:08 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> 
> > On Wed, 15 Dec 2010 06:15:40 +0100
> > Andrea Arcangeli <aarcange@xxxxxxxxxx> wrote:
> > 
> > > Some of some relevant user of the project:
> > > 
> > > KVM Virtualization
> > > GCC (kernel build included, requires a few liner patch to enable)
> > > JVM
> > > VMware Workstation
> > > HPC
> > > 
> > > It would be great if it could go in -mm.
> > 
> > Things should be done in memory cgroup is
> >  
> >  - make accounting correct (RSS count will be broken)
> >  - make move_charge() to work
> >    (at rmdir(), this is now broken. It seems move-charge-at-task-move to work)
> > 
> Yes.
> I think we should add mem_cgroup_split_hugepage_commit() and add PageTransHuge()
> check in mem_cgroup_move_parent() as done in RHEL6 kernel.

Yes, unfortunately porting all the RHEL6 THP cgroups bits wasn't
trivial because of the difference in the cgroup code.

> As for move-charge-at-task-move, it will work because walk_pmd_range() splits
> THP pages(it would be better to change move-charge not to split THP pages, but
> it's not so urgent IMHO).
> 
> > Do you have known other viewpoints ?
> Not yet, but I'll test and check.

Same here.

One detail I'd ask you to check is the compound_trans_order I added in
#33 for memory-failure and cgroups. It's not really necessary in memcg
if we stop reading the order and we do page_size = HPAGE_PMD_SIZE
instead. I thought having the cgroup code handling compound pages
without hardwiring the size was better but maybe it's not. Maybe the
compound_lock locking should also be extended there? It's up to you to
what you prefer there but I'll try to help as much as I can.

BTW, now that it's in -mm I'll keep any further change incremental at
the end and I'll stop rebasing to avoid confusion.

> > I'll look into when -mm is shipped.
> > 
> me too :)

Thanks a lot!
--
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/