linux-kernel - Re: [PATCH v2 00/20] mm, hugetlb: remove a hugetlb_instantiation

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: <CAAmzW4PpPqGYpGY=zkMmrwLWgQH9xxOb9r3iwzVrWmgcWFbxzQ@mail.gmail.com>
Date:	Sat, 17 Aug 2013 02:18:55 +0900
From:	JoonSoo Kim <js1304@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...e.de>,
	Michal Hocko <mhocko@...e.cz>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Hugh Dickins <hughd@...gle.com>,
	Davidlohr Bueso <davidlohr.bueso@...com>,
	David Gibson <david@...son.dropbear.id.au>,
	Linux Memory Management List <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Wanpeng Li <liwanp@...ux.vnet.ibm.com>,
	Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
	Hillf Danton <dhillf@...il.com>
Subject: Re: [PATCH v2 00/20] mm, hugetlb: remove a hugetlb_instantiation_mutex

2013/8/15 Andrew Morton <akpm@...ux-foundation.org>:
> On Fri,  9 Aug 2013 18:26:18 +0900 Joonsoo Kim <iamjoonsoo.kim@....com> wrote:
>
>> Without a hugetlb_instantiation_mutex, if parallel fault occur, we can
>> fail to allocate a hugepage, because many threads dequeue a hugepage
>> to handle a fault of same address. This makes reserved pool shortage
>> just for a little while and this cause faulting thread to get a SIGBUS
>> signal, although there are enough hugepages.
>>
>> To solve this problem, we already have a nice solution, that is,
>> a hugetlb_instantiation_mutex. This blocks other threads to dive into
>> a fault handler. This solve the problem clearly, but it introduce
>> performance degradation, because it serialize all fault handling.
>>
>> Now, I try to remove a hugetlb_instantiation_mutex to get rid of
>> performance problem reported by Davidlohr Bueso [1].
>>
>> This patchset consist of 4 parts roughly.
>>
>> Part 1. (1-6) Random fix and clean-up. Enhancing error handling.
>>
>>       These can be merged into mainline separately.
>>
>> Part 2. (7-9) Protect region tracking via it's own spinlock, instead of
>>       the hugetlb_instantiation_mutex.
>>
>>       Breaking dependency on the hugetlb_instantiation_mutex for
>>       tracking a region is also needed by other approaches like as
>>       'table mutexes', so these can be merged into mainline separately.
>>
>> Part 3. (10-13) Clean-up.
>>
>>       IMO, these make code really simple, so these are worth to go into
>>       mainline separately, regardless success of my approach.
>>
>> Part 4. (14-20) Remove a hugetlb_instantiation_mutex.
>>
>>       Almost patches are just for clean-up to error handling path.
>>       In patch 19, retry approach is implemented that if faulted thread
>>       failed to allocate a hugepage, it continue to run a fault handler
>>       until there is no concurrent thread having a hugepage. This causes
>>       threads who want to get a last hugepage to be serialized, so
>>       threads don't get a SIGBUS if enough hugepage exist.
>>       In patch 20, remove a hugetlb_instantiation_mutex.
>
> I grabbed the first six easy ones.  I'm getting a bit cross-eyed from
> all the reviewing lately so I'll wait and see if someone else takes an
> interest in the other patches, sorry.

Hello, Andrew.
Thanks for reviewing this and merging the first six patches.
There is no hurry to me, so I'd willingly wait for someone to review this.

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