From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by kanga.kvack.org (Postfix) with ESMTP id DEE166B0075 for ; Fri, 20 Dec 2013 09:01:59 -0500 (EST) Received: by mail-ee0-f46.google.com with SMTP id d49so1072739eek.19 for ; Fri, 20 Dec 2013 06:01:59 -0800 (PST) Received: from mx2.suse.de (cantor2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id w6si8901466eeg.27.2013.12.20.06.01.58 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 20 Dec 2013 06:01:59 -0800 (PST) Date: Fri, 20 Dec 2013 14:01:53 +0000 From: Mel Gorman Subject: Re: [PATCH v3 13/14] mm, hugetlb: retry if failed to allocate and there is concurrent user Message-ID: <20131220140153.GC11295@suse.de> References: <1387349640-8071-1-git-send-email-iamjoonsoo.kim@lge.com> <1387349640-8071-14-git-send-email-iamjoonsoo.kim@lge.com> <20131219170202.0df2d82a2adefa3ab616bdaa@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20131219170202.0df2d82a2adefa3ab616bdaa@linux-foundation.org> Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: Joonsoo Kim , Rik van Riel , Michal Hocko , "Aneesh Kumar K.V" , KAMEZAWA Hiroyuki , Hugh Dickins , Davidlohr Bueso , David Gibson , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joonsoo Kim , Wanpeng Li , Naoya Horiguchi , Hillf Danton On Thu, Dec 19, 2013 at 05:02:02PM -0800, Andrew Morton wrote: > On Wed, 18 Dec 2013 15:53:59 +0900 Joonsoo Kim wrote: > > > 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 who can get hugepages to get a SIGBUS signal. > > > > 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 degradation. > > So the whole point of the patch is to improve performance, but the > changelog doesn't include any performance measurements! > I don't really deal with hugetlbfs any more and I have not examined this series but I remember why I never really cared about this mutex. It wrecks fault scalability but AFAIK fault scalability almost never mattered for workloads using hugetlbfs. The most common user of hugetlbfs by far is sysv shared memory. The memory is faulted early in the lifetime of the workload and after that it does not matter. At worst, it hurts application startup time but that is still poor motivation for putting a lot of work into removing the mutex. Microbenchmarks will be able to trigger problems in this area but it'd be important to check if any workload that matters is actually hitting that problem. -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org