From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 16B32C282DD for ; Thu, 9 Jan 2020 17:03:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CE05D20661 for ; Thu, 9 Jan 2020 17:03:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE05D20661 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 602508E0006; Thu, 9 Jan 2020 12:03:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B13E8E0005; Thu, 9 Jan 2020 12:03:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C73E8E0006; Thu, 9 Jan 2020 12:03:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0052.hostedemail.com [216.40.44.52]) by kanga.kvack.org (Postfix) with ESMTP id 3B0488E0005 for ; Thu, 9 Jan 2020 12:03:29 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id EA229125C for ; Thu, 9 Jan 2020 17:03:28 +0000 (UTC) X-FDA: 76358716896.23.tail69_3b71cae6a114b X-HE-Tag: tail69_3b71cae6a114b X-Filterd-Recvd-Size: 2912 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Thu, 9 Jan 2020 17:03:28 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id EAFC2AE03; Thu, 9 Jan 2020 17:03:24 +0000 (UTC) Date: Thu, 9 Jan 2020 18:03:18 +0100 From: Michal Hocko To: Vlastimil Babka Cc: "Kirill A. Shutemov" , Matthew Wilcox , linux-mm@kvack.org, Peter Zijlstra Subject: Re: Splitting the mmap_sem Message-ID: <20200109170318.GU4951@dhcp22.suse.cz> References: <20191203222147.GV20752@bombadil.infradead.org> <20191212142457.zqp4mawjz7frpyvk@box> <20191212154002.GR32169@bombadil.infradead.org> <20200106220910.GK6788@bombadil.infradead.org> <20200107123415.gqklwca4qilva2yr@box> <20200107135459.GL6788@bombadil.infradead.org> <20200107142714.gjkdcikbbwfbvl2r@box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu 09-01-20 14:56:48, Vlastimil Babka wrote: > +CC > > On 1/7/20 3:27 PM, Kirill A. Shutemov wrote: > >>>> Option 2: Add a memalloc_nowait_save/restore API to go along > >>>> with nofs and noio. That way, we can take the RCU read lock, call > >>>> memalloc_nowait_save(), and walk the VMA tree and the page tables in > >>>> the current order. There's an increased chance of memory allocation of > >>>> page tables failing, so we'll have to risk that and do a retry with the > >>>> reference count held on the VMA if we need to sleep to allocate memory. > >>>> > >>>> Option 3: Variant of 2 where we add GFP flags to the p??_alloc() > >>>> functions. > >>> > >>> I think this is the most reasonable way. If we are low of memory, latency > >>> is not on the top of priorities. > >> > >> You prefer adding GFP flags over adding a memalloc_nowait_save()? > > > > I don't have strong preference here. > > I think it's generally a good idea to have the memalloc_() scoping. I also think there are going to be other usecases where NOWAIT scoping would be interesting. I am not sure this is the case for the page tables allocation though. I might misremember but RCU based VMA handling has been considered in the past. I do not remember details but there were some problems and page tables allocation is not the biggest one. > However, we use the PF_* flags where it now seems 30 out of 32 are used, > and MEMALLOC* already occupies 3 of those. This shouldn't be a big deal. Adding a single int to the struct page shouldn't be terribly hard. -- Michal Hocko SUSE Labs