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 73DBAC433EF for ; Tue, 26 Oct 2021 14:27:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0746A60E8F for ; Tue, 26 Oct 2021 14:27:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0746A60E8F 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 640A280007; Tue, 26 Oct 2021 10:27:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5EFE0940007; Tue, 26 Oct 2021 10:27:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4B7E280007; Tue, 26 Oct 2021 10:27:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0170.hostedemail.com [216.40.44.170]) by kanga.kvack.org (Postfix) with ESMTP id 3BACA940007 for ; Tue, 26 Oct 2021 10:27:17 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E7609184793EB for ; Tue, 26 Oct 2021 14:27:16 +0000 (UTC) X-FDA: 78738816072.34.FE1DD2C Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf25.hostedemail.com (Postfix) with ESMTP id 70273B000185 for ; Tue, 26 Oct 2021 14:27:10 +0000 (UTC) Received: by mail-ed1-f53.google.com with SMTP id z20so1253821edi.0 for ; Tue, 26 Oct 2021 07:27:16 -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=ZkJRL0lPRthFxQ90psMtV6Y2lcv2PWeua158fYiZ2tE=; b=VtSn4Qsf+26WNtb9faKkgDJYjE+Y/NifymUBTasTLjEZHV5DjzChjuKMOzrM9ga++F +2LSiHWb+HVvmU70Qason5S/qaPC2Av3LXUmXx9QzXYYMpqvfYqHjuSruE/KAZVkvGLz InCwl55UA0vUpA8Zc3p3TZQYuF0bBNSrD/hLOC65yHokL8hXfHDe2Npgdq7xFEZOf1Se 4/aVyntg8sQwpAtHFMH3suBvpy2mQzuIU7IaXbblOMNzfIojyISlS5gqm3pxsJCo83vD sPQFh7HLO1dpSUT0fDnNLNAylF8pOb5oG4/g7EvAs0bZXTW8URjYww9v1aRPdQk+83yL gY3w== 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=ZkJRL0lPRthFxQ90psMtV6Y2lcv2PWeua158fYiZ2tE=; b=XWq9RCN2QqDnSUD9YkO4eKg0Hic+BSUoQT7xbgGHuZ45gh4QjA1kyCVbeuqNbvdhAa rBboTbJ+AZhH2bej79cJdd3qBvG9lcDOnXdRaNxKrJ1L8R8K2PbbfbEHDnficHfGmgfo VVxfUNt0v2H4B5pkSZhxn4iJ/sIDQFctHXihHVQy5wIzXa34W6DxZcQFg8CwrleolHzv cmRw1vcDVEbZNBbNuG6CSVr22R90rg75Bb2nvmgs3QhCYXvG8dggl8IoAMhdAUZ8vE5N AzODe/PDv8WGpA9iUADQfzzyRPnyv/vW3WT6roCyWBiyJ2v7Fhjz50GK8EI1hTWLoyZK g3zw== X-Gm-Message-State: AOAM533tNB9XLhBX4MW7c5ZvHRZ9364YrGQxki3HdsouyQMzQ/4MbNfx kDbM4T8cFpQFQnnSLQz1gHSagFIJheHQthlIRIM= X-Google-Smtp-Source: ABdhPJzAbha01GzhYnNbtdP2nscjIzf9PN4ekdMn/3Fr8Wwd9C8/kUL/KLZ68gKE8NdMa8m5PpRRMxEYjLqzD9/sJ88= X-Received: by 2002:a17:907:d08:: with SMTP id gn8mr30687462ejc.395.1635258318314; Tue, 26 Oct 2021 07:25:18 -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: <163524388152.8576.15706993879941541847@noble.neil.brown.name> From: Uladzislau Rezki Date: Tue, 26 Oct 2021 16:25:07 +0200 Message-ID: Subject: Re: [RFC 2/3] mm/vmalloc: add support for __GFP_NOFAIL To: NeilBrown , Michal Hocko Cc: 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: 70273B000185 X-Stat-Signature: m9y64cfphfkngan7ph6fgwopmikn7fzd Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VtSn4Qsf; spf=pass (imf25.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.53 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1635258430-579978 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 Tue, Oct 26, 2021 at 12:24 PM NeilBrown wrote: > > On Tue, 26 Oct 2021, Michal Hocko wrote: > > On Tue 26-10-21 10:50:21, Neil Brown wrote: > > > On Mon, 25 Oct 2021, Uladzislau Rezki wrote: > > > > On Fri, Oct 22, 2021 at 09:49:08AM +1100, NeilBrown wrote: > > > > > However I'm not 100% certain, and the behaviour might change in the > > > > > future. So having one place (the definition of memalloc_retry_wait()) > > > > > where we can change the sleeping behaviour if the alloc_page behavour > > > > > changes, would be ideal. Maybe memalloc_retry_wait() could take a > > > > > gfpflags arg. > > > > > > > > > At sleeping is required for __get_vm_area_node() because in case of lack > > > > of vmap space it will end up in tight loop without sleeping what is > > > > really bad. > > > > > > > So vmalloc() has two failure modes. alloc_page() failure and > > > __alloc_vmap_area() failure. The caller cannot tell which... > > > > > > Actually, they can. If we pass __GFP_NOFAIL to vmalloc(), and it fails, > > > then it must have been __alloc_vmap_area() which failed. > > > What do we do in that case? > > > Can we add a waitq which gets a wakeup when __purge_vmap_area_lazy() > > > finishes? > > > If we use the spinlock from that waitq in place of free_vmap_area_lock, > > > then the wakeup would be nearly free if no-one was waiting, and worth > > > while if someone was waiting. > > > > 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. -- Uladzislau Rezki