Re: [PATCH v2 00/20] mm, hugetlb: remove a hugetlb_instantiation_mutex

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2013/8/15 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>:
> On Fri,  9 Aug 2013 18:26:18 +0900 Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]