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 A612CC433FE for ; Fri, 29 Oct 2021 17:23:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1D9DD60FF2 for ; Fri, 29 Oct 2021 17:23:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1D9DD60FF2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 60DAA940008; Fri, 29 Oct 2021 13:23:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5953F940007; Fri, 29 Oct 2021 13:23:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43670940008; Fri, 29 Oct 2021 13:23:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0151.hostedemail.com [216.40.44.151]) by kanga.kvack.org (Postfix) with ESMTP id 14B7A940007 for ; Fri, 29 Oct 2021 13:23:12 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A0B8031E6D for ; Fri, 29 Oct 2021 17:23:11 +0000 (UTC) X-FDA: 78750145824.17.8E7C9CD Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf25.hostedemail.com (Postfix) with ESMTP id 0AE93B00008E for ; Fri, 29 Oct 2021 17:23:03 +0000 (UTC) Received: by mail-lf1-f54.google.com with SMTP id j2so22408166lfg.3 for ; Fri, 29 Oct 2021 10:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=EtICLvOv8UaC285aDmyhMlK7DAYybzG+Y+RAGwhmM18=; b=gYuFZcrJIhGRvYmSW8nQ+XPuTgZps4MjJQh4pG0VrVIpuc7q5pXe920s8duO2rYy34 GcpJg5tl7YZ2YudjJgX5pXy4J6vUf4/CcuTmSiAztjQNk4VsU2x4xsMCSN0ghDJb55t6 fHI/Ii4Be2J6au1p4YPsGKKd3tDJ4j3xZPA7oWk/eLKWzvdsN7pYxGy7VGwr6GZQzbGZ 30Z0yiGYVIFJQL6Eg8xzyACurG2sdamkqo0oWVz0lLSeeFRvIIVczK64xr9ILG6NNi89 3cgehjevCtUE8Y8Dw7UKEGiKFkeIoSkqWPtHXvjefYXAuSV+ihkytBSTHPJSDiC362QR JQ6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=EtICLvOv8UaC285aDmyhMlK7DAYybzG+Y+RAGwhmM18=; b=V+q2eqg0TAe7VU7C3CD8QAHiblcfgrn4m7Bm3VYqvHk9K25AD1ZdtGPRaRpON0BSwV nnMxTQYVa8VA51Bt8WezLpmBg6xLMgJOoLAlD8UVRXnrZFzXqavzACMbXHUt4/sWMjSX uuL1c/IEmIdrV7jiamL0pg4uiZEIEF2KDE47QzJhibkLc5EZlP1yb0bB+xkSFIiOja3w YAaz75kDQs1Y2pmVI8EKOD6QQGxujI9ysIY9KcRAkAB+q0ku7tIXrikbra6PKz0cnMmi UqS3cn+WB71fppeXUYJHVwUAdOe2EEktHGrl0B2Oq5ODMJJIixRYEBArIbYxEM4AeRpC n8+Q== X-Gm-Message-State: AOAM5329x3dvdJ2Pqj8LCIcla/i5ExdiWPS0G3JC7DctlOwE95MEyOpQ kduCbW2olKMFlNOW9egkSXA= X-Google-Smtp-Source: ABdhPJwdOMwxkjcWALwL5I2JMfEx0RECCkgsie7pTY3b2aQ4SHUsBKVPJVZZKx8zMYENaRsy2OSMUw== X-Received: by 2002:ac2:5444:: with SMTP id d4mr12051574lfn.559.1635528189684; Fri, 29 Oct 2021 10:23:09 -0700 (PDT) Received: from pc638.lan (h5ef52e3d.seluork.dyn.perspektivbredband.net. [94.245.46.61]) by smtp.gmail.com with ESMTPSA id m4sm656638lfu.107.2021.10.29.10.23.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Oct 2021 10:23:09 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 29 Oct 2021 19:23:07 +0200 To: Michal Hocko Cc: Uladzislau Rezki , 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: <20211029172307.GA2944@pc638.lan> 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: User-Agent: Mutt/1.10.1 (2018-07-13) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=gYuFZcrJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.54 as permitted sender) smtp.mailfrom=urezki@gmail.com X-Stat-Signature: xhxie4qhraa3s3pfrsd4w9358egsojc7 X-Rspamd-Queue-Id: 0AE93B00008E X-Rspamd-Server: rspam01 X-HE-Tag: 1635528183-412724 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. > We are not talking about performance, no sense to measure cycles here :) > > So unless you really feel strongly about this then I would stick with > this approach. > I have raised one concern. The memory resource is shared between all process in case of __GFP_NOFAIL it might be that we never return back to user in that scenario i prefer to release hold memory for other needs instead of keeping it for nothing. If you think it is not a problem, then i do not have much to say. -- Vlad Rezki