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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D519C433EF for ; Fri, 29 Oct 2021 14:45:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E9432611CB for ; Fri, 29 Oct 2021 14:45:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E9432611CB Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 29F76940007; Fri, 29 Oct 2021 10:45:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24D546B0072; Fri, 29 Oct 2021 10:45:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0EF0E940007; Fri, 29 Oct 2021 10:45:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id DE9246B0071 for ; Fri, 29 Oct 2021 10:45:06 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6886A8249980 for ; Fri, 29 Oct 2021 14:45:06 +0000 (UTC) X-FDA: 78749747412.30.CDE0D96 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf05.hostedemail.com (Postfix) with ESMTP id AFD5E508B664 for ; Fri, 29 Oct 2021 14:44:53 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 838231FD51; Fri, 29 Oct 2021 14:45:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1635518704; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=g1/0tWG/oKUZOJcGNfnoYQFpXXezjJ1VuVMjD4tPxqM=; b=rkUaNJDo7doW7mmhhiDH23/fksZk9/bMewZMBKvw02s5xGKVCoudDBJeVnactwhApDzRwr OI0C5as/v7+QVSF+ha+hHzbuqZxPwcjsgaLG4Qe8DlVjFknnk/wGBfoq5ay8+iOEOI5xp9 zC7B3XezoovoCrndutFf6IWjryp3H2g= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 549CAA3B84; Fri, 29 Oct 2021 14:45:04 +0000 (UTC) Date: Fri, 29 Oct 2021 16:45:03 +0200 From: Michal Hocko To: Uladzislau Rezki Cc: Linux Memory Management List , Dave Chinner , Neil Brown , Andrew Morton , Christoph Hellwig , linux-fsdevel@vger.kernel.org, LKML , Ilya Dryomov , Jeff Layton Subject: Re: [PATCH 2/4] mm/vmalloc: add support for __GFP_NOFAIL Message-ID: References: <20211025150223.13621-1-mhocko@kernel.org> <20211025150223.13621-3-mhocko@kernel.org> <20211026193315.GA1860@pc638.lan> <20211027175550.GA1776@pc638.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: AFD5E508B664 X-Stat-Signature: y47ebfyrgpz9zfxhd9xe84y6uzoi4ocz Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=rkUaNJDo; spf=pass (imf05.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-HE-Tag: 1635518693-591311 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 Fri 29-10-21 16:05:32, Uladzislau Rezki wrote: [...] > > OK, this looks easier from the code reading but isn't it quite wasteful > > to throw all the pages backing the area (all of them allocated as > > __GFP_NOFAIL) just to then fail to allocate few page tables pages and > > drop all of that on the floor (this will happen in __vunmap AFAICS). > > > > I mean I do not care all that strongly but it seems to me that more > > changes would need to be done here and optimizations can be done on top. > > > > Is this something you feel strongly about? > > > Will try to provide some motivations :) > > It depends on how to look at it. My view is as follows a more simple code > is preferred. It is not considered as a hot path and it is rather a corner > case to me. Yes, we are definitely talking about corner cases here. Even GFP_KERNEL allocations usually do not fail. > I think "unwinding" has some advantage. At least one motivation > is to release a memory(on failure) before a delay that will prevent holding > of extra memory in case of __GFP_NOFAIL infinitelly does not succeed, i.e. > if a process stuck due to __GFP_NOFAIL it does not "hold" an extra memory > forever. Well, I suspect this is something that we can disagree on and both of us would be kinda right. I would see it as throwing baby out with the bathwater. The vast majority of the memory will be in the area pages and sacrificing that just to allocate few page tables or whatever that might fail in that code path is just a lot of cycles wasted. So unless you really feel strongly about this then I would stick with this approach. -- Michal Hocko SUSE Labs