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 07FE6C433EF for ; Tue, 26 Oct 2021 15:42:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B8C466109E for ; Tue, 26 Oct 2021 15:42:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B8C466109E 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 0B99D940008; Tue, 26 Oct 2021 11:42:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 041C0940007; Tue, 26 Oct 2021 11:42:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E2449940008; Tue, 26 Oct 2021 11:42:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D02C7940007 for ; Tue, 26 Oct 2021 11:42:56 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7BCD4269B0 for ; Tue, 26 Oct 2021 15:42:56 +0000 (UTC) X-FDA: 78739006752.35.D74541C Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf23.hostedemail.com (Postfix) with ESMTP id 7861A90000A6 for ; Tue, 26 Oct 2021 15:42:48 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id y12so16851155eda.4 for ; Tue, 26 Oct 2021 08:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T4M/22FGw7e6SSuR5+lAvRn2uYeHyXsIaqiFpPFs7GM=; b=fLE5FaJ7rSAWggLqi5i/+7DBIp3Y1MLINJl7IInXpX/M/SMHMaEnlea8EP/eli4Rbi FGnhzsqSa1IHRPlv16Fl3FiQ3037bmP6vCyLIlnT8X9cNn/yERfSSWntfqcBLBZbNBb6 CG1OGMgcixKEC73YyzjNFhXFsU8enn7tNqODq1d5LSBPPnW+MZRbOpwxJ52WwCNgx/Tt 6KV4cvLRt69SFEuQ2gqa0nOjaRsv7ApGMvTmxh3hFELX69O97XIZF20Tc4PtOD00462w zSraUZQWUCGLDM6RcXBV1tJcX19NTtFcAKhqQ0Tdx2Jo+38EwEuNRCFAPKqcveo5VNb1 Ts2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T4M/22FGw7e6SSuR5+lAvRn2uYeHyXsIaqiFpPFs7GM=; b=moMwPkNPcGyu3gvoLy465bjkXsb3fvd/P1QIf2Dum9iJ70SlaGNjV+j1rUXcsgSn6k sdHdK/7m7Tdc64LCvfXk+nKBJuK9uRwAAa5Mg0WRZZPseC7Fq5jbSc8omnMdCmQwydM/ vjWmrU1fjolZgicllCUk9cJFIIYid6MhEk//ds8sMos6AVZtZi3ENIsBSfA9zXfIRScS dHWxYee4NkgStgQDX5zhrju18hVzudU2o1/9ZRBb2jqZ6rMUvAmrgAJ0WUw7+i3xmfTe EqAI2Ywr5y8mn9HnrZr0BSRrkXksBPWcAacQe3VcrjkxVBwMs/lArVMHQHa/7RPG7e1K p5fQ== X-Gm-Message-State: AOAM533W81JEbZLPDEiPzhYpWZlVrTBnL+S71Ilq9ckUk2D7OoCmSC99 esUI5H6NrZ8ydvYXewzwVSLxlSmuDtYINUhmvUE= X-Google-Smtp-Source: ABdhPJxHqML5RddOenfRBlL1vPTQYiXn+SaTgxIuuPWFvPtteHluOBrnxEczYR4MVa+OooX2R/p1c7LAPGiSDW7qFUY= X-Received: by 2002:a05:6402:3488:: with SMTP id v8mr36306045edc.106.1635262845117; Tue, 26 Oct 2021 08:40:45 -0700 (PDT) MIME-Version: 1.0 References: <20211020192430.GA1861@pc638.lan> <163481121586.17149.4002493290882319236@noble.neil.brown.name> <20211021104038.GA1932@pc638.lan> <163485654850.17149.3604437537345538737@noble.neil.brown.name> <20211025094841.GA1945@pc638.lan> <163520582122.16092.9250045450947778926@noble.neil.brown.name> <163524388152.8576.15706993879941541847@noble.neil.brown.name> In-Reply-To: From: Uladzislau Rezki Date: Tue, 26 Oct 2021 17:40:33 +0200 Message-ID: Subject: Re: [RFC 2/3] mm/vmalloc: add support for __GFP_NOFAIL To: Michal Hocko Cc: NeilBrown , Linux Memory Management List , Dave Chinner , Andrew Morton , Christoph Hellwig , linux-fsdevel@vger.kernel.org, LKML , Ilya Dryomov , Jeff Layton Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 7861A90000A6 X-Stat-Signature: gzbt6xyfra4wtchp5ntgptct17kbypky Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=fLE5FaJ7; spf=pass (imf23.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1635262968-952798 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: > > > > Is this really required to be part of the initial support? > > > > > > No.... I was just thinking out-loud. > > > > > alloc_vmap_area() has an retry path, basically if it fails the code > > will try to "purge" > > areas and repeat it one more time. So we do not need to purge outside some where > > else. > > I think that Neil was not concerned about the need for purging something > but rather a waiting event the retry loop could hook into. So that the > sleep wouldn't have to be a random timeout but something that is > actually actionable - like somebody freeing an area. > I see this point. But sometimes it is not as straightforward as it could be. If we have lack of vmap space within a specific range, it might be not about reclaiming(nobody frees to that area and no outstanding areas) thus we can do nothing. -- Uladzislau Rezki