Re: Transparent Hugepage Support #30

From: Balbir Singh
Date: Thu Sep 09 2010 - 06:46:59 EST


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

> http://www.linux-kvm.org/wiki/images/9/9e/2010-forum-thp.pdf
>
> http://git.kernel.org/?p=linux/kernel/git/andrea/aa.git;a=shortlog
>
> first: git clone git://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git
> or first: git clone --reference linux-2.6 git://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git
> later: git fetch; git checkout -f origin/master
>
> The tree is rebased and git pull won't work.
>
> http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.36-rc3/transparent_hugepage-30/
> http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.36-rc3/transparent_hugepage-30.gz
>
> Diff #29 -> #30:
>
> b/compaction-migration-warning | 25 +++
>
> Avoid MIGRATION config warning when COMPACTION is selected but numa
> and memhotplug aren't.
>
> do_swap_page-VM_FAULT_WRITE | 21 --
> kvm-huge-spte-wrprotect | 48 ------
> kvm-mmu-notifier-huge-spte | 29 ---
> root_anon_vma-anon_vma_lock | 208 ---------------------------
> root_anon_vma-avoid-ksm-hang | 30 ---
> root_anon_vma-bugchecks | 37 ----
> root_anon_vma-in_vma | 27 ---
> root_anon_vma-ksm_refcount | 169 ---------------------
> root_anon_vma-lock_root | 127 ----------------
> root_anon_vma-memory-compaction | 36 ----
> root_anon_vma-mm_take_all_locks | 81 ----------
> root_anon_vma-oldest_root | 81 ----------
> root_anon_vma-refcount | 29 ---
> root_anon_vma-swapin | 91 -----------
> root_anon_vma-use-root | 66 --------
> root_anon_vma-vma_lock_anon_vma | 94 ------------
>
> merged upstream.
>
> b/memcg_compound | 166 ++++++++++-----------
> b/memcg_compound_tail | 31 +---
> b/memcg_consume_stock | 31 ++--
> memcg_check_room | 88 -----------
> memcg_oom | 34 ----
>
> These had heavy rejects, the last two patches and other bits got
> removed. memcg code is rewritten so fast it's hard to justify to keep
> up with it. It's simpler and less time consuming to fix it just once
> than over and over again. Likely memcg in this release isn't too
> stable with THP on (it'll definitely work fine if you disable THP at
> compile time or at boot time with the kernel parameter). Especially
> all get_css/put_css will have to be re-audited after these new
> changes. For now it builds just fine and the basics to support THP and
> to show the direction are in. Nevertheless I welcome patches to fix
> this up.
>
> 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?

> partly up to them to want to support THP in memcg, but it's also
> perfectly ok to catch up with memcg externally, but it'd be also nice
> to know when memcg reaches a milestone and so when it's time to
> re-audit it all for THP.
>

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.

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