linux-kernel - Re: Transparent Hugepage Support #30

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100915134200.GD5981@random.random>
Date:	Wed, 15 Sep 2010 15:42:00 +0200
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Balbir Singh <balbir@...ux.vnet.ibm.com>
Cc:	linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Adam Litke <agl@...ibm.com>, Avi Kivity <avi@...hat.com>,
	Izik Eidus <ieidus@...hat.com>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>,
	Nick Piggin <npiggin@...e.de>, Rik van Riel <riel@...hat.com>,
	Mel Gorman <mel@....ul.ie>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Ingo Molnar <mingo@...e.hu>, Mike Travis <travis@....com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Chris Wright <chrisw@...s-sol.org>, bpicco@...hat.com,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Daisuke Nishimura <nishimura@....nes.nec.co.jp>,
	Chris Mason <chris.mason@...cle.com>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: Transparent Hugepage Support #30

Hello,

On Mon, Sep 13, 2010 at 03:04:09PM +0530, Balbir Singh wrote:
> OK, when the code is touched next and from now on, we'll stop making
> that assumption.

Great, thanks!

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

The compound lock is a per-page bit spinlock, so it'll surely scale
well, but surely there is a locked op overhead associated to it, but
it will only cost for hugepages, not normal pages.

Hugepages can't be collapsed in place, and they can only be collapsed
under the mmap_sem write mode (so holding the mmap sem in read or
write mode is enough to protect against it). The same can't be said
for the split of an hugepage, hugepages can be splitted under the mmap
sem just fine (the only way to protect against it is the compound_lock
or the anon_vma_lock, or yet another way to avoid the page to be
splitted under us is to local_irq_disable and then call
__get_user_pages_fast like futex.c does, it can't be splitted until
local_irq_enable is called, same guarantee as in gup_fast, the
pmd_splitting_flush_notify will wait, the tlb flush for the splitting
is really useless, it's just there to send an IPI and wait for any
gup_fast to finish). It's not entirely clear right now, what kind of
protection we need in memcg.

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

Looking at it right now!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/