On Fri, 9 Aug 2013 18:26:18 +0900 Joonsoo Kim <iamjoonsoo....@lge.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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
