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 8CEF8C433F5 for ; Wed, 20 Oct 2021 13:56:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2777C6128B for ; Wed, 20 Oct 2021 13:56:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2777C6128B 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 96C0E6B0072; Wed, 20 Oct 2021 09:56:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 91B846B0073; Wed, 20 Oct 2021 09:56:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 80A93900002; Wed, 20 Oct 2021 09:56:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0096.hostedemail.com [216.40.44.96]) by kanga.kvack.org (Postfix) with ESMTP id 748806B0072 for ; Wed, 20 Oct 2021 09:56:23 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 30B0422003 for ; Wed, 20 Oct 2021 13:56:23 +0000 (UTC) X-FDA: 78716965446.25.B534999 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf21.hostedemail.com (Postfix) with ESMTP id F0AF8D042B5F for ; Wed, 20 Oct 2021 13:56:20 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id y30so24282807edi.0 for ; Wed, 20 Oct 2021 06:56:22 -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=SCdZv2e62ABN56MTTs5oGH5NMRs9ClTsnNTNWpGbnRI=; b=EWbY5Dviy2DZHiyOZzbGQdERHZ5KvL4s7Ss6sUG1m1LFp1YBswM4l3xWhZJ9KBIXSa ZbE/ZcVpj+Bu+ITXVL5JPqRYFCmU9nCrxOYYoWxLI32qSHR71pakJpYF6ecm6HpJ8S70 spltE1Vt266lFklnDyfGnTEj8Qc9UxcyrXaPDzp6R+9fYcHPoSYV3HxebnPniplf2W+F HJLBY27lOXxAM/Z129If7+XZHN0TkB5WppNubldHfisAQ2zeMTshWl8NUaqMHWlfbBF5 cPdCCdFHumG1gwhRrNh0fg6vxxpiNwxd6ZVCjff13eVd8dfT0ZYG8iuysKU1jAa5h1TZ eyNQ== 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=SCdZv2e62ABN56MTTs5oGH5NMRs9ClTsnNTNWpGbnRI=; b=3XMO5Z0J3V0Z/tpjLlNesUlmyBuRnZQon29Eqn3O/I84uJcFgFv1JuW+NPWwvPGrcs byleMFITwcpl4RPGcsWdZRaPSxfxPil2K1RWX9Fy61OKcEgXYGPQGIRIhr8sQE5N2hB/ YBl2xiTXtHgjH+vGUxtp6SR3dIDkaFewiNBxaed0ef4QGRm3UizLE7ugq1nQXgv8p08f BFfIJALVuneWk45NjYP3LCeRUcMBKPDNUp7fJflOnEi0qWNaQ2gjSLwHNPZXn++OBpQL Lnng/pKutpEXrNYT739/KByUdl1GIWLT7UOZrc+MgDsVRrCP6z+uFiUp4g6sIMSt8vIh qWCA== X-Gm-Message-State: AOAM530tySy7qRm8IwACtx5f6glU+hLzXjWtmlSuqpIOZm/TksMvkhyZ tol47v+wAqOX2wkxpqEXZRUkeNv5oFmXnPs7eC4= X-Google-Smtp-Source: ABdhPJyFR5arm+ejse92keU//979Z9636AyxL7WCQcldmVzN3fnBF5ek60aXn5jd8eDKIfCmlUL+lgszFqWqOr01MYM= X-Received: by 2002:a05:6402:3488:: with SMTP id v8mr218009edc.106.1634738074303; Wed, 20 Oct 2021 06:54:34 -0700 (PDT) MIME-Version: 1.0 References: <20211018114712.9802-1-mhocko@kernel.org> <20211018114712.9802-3-mhocko@kernel.org> <20211019110649.GA1933@pc638.lan> <20211019194658.GA1787@pc638.lan> In-Reply-To: From: Uladzislau Rezki Date: Wed, 20 Oct 2021 15:54:23 +0200 Message-ID: Subject: Re: [RFC 2/3] mm/vmalloc: add support for __GFP_NOFAIL To: Michal Hocko Cc: Linux Memory Management List , Dave Chinner , Neil Brown , Andrew Morton , Christoph Hellwig , linux-fsdevel@vger.kernel.org, LKML , Ilya Dryomov , Jeff Layton Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: F0AF8D042B5F X-Stat-Signature: hmfhh3bah13gac1gtajcpeaa1jqqdrqr Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=EWbY5Dvi; spf=pass (imf21.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: 1634738180-370588 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: > > > > > I think adding kind of schedule() will not make things worse and in corner > > cases could prevent a power drain by CPU. It is important for mobile devices. > > I suspect you mean schedule_timeout here? Or cond_resched? I went with a > later for now, I do not have a good idea for how to long to sleep here. > I am more than happy to change to to a sleep though. > cond_resched() reschedules only if TIF_NEED_RESCHED is raised what is not good here. Because in our case we know that we definitely would like to take a breath. Therefore invoking the schedule() is more suitable here. It will give a CPU time to another waiting process(if exists) in any case putting the "current" one to the tail. As for adding a delay. I am not sure about for how long to delay or i would say i do not see a good explanation why for example we delay for 10 milliseconds or so. > > As for vmap space, it can be that a user specifies a short range that does > > not contain any free area. In that case we might never return back to a caller. > > This is to be expected. The caller cannot fail and if it would be > looping around vmalloc it wouldn't return anyway. > > > Maybe add a good comment something like: think what you do when deal with the > > __vmalloc_node_range() and __GFP_NOFAIL? > > We have a generic documentation for gfp flags and __GFP_NOFAIL is > docuemented to "The allocation could block indefinitely but will never > return with failure." We are discussing improvements for the generic > documentation in another thread [1] and we will likely extend it so I > suspect we do not have to repeat drawbacks here again. > > [1] http://lkml.kernel.org/r/163184741778.29351.16920832234899124642.stgit@noble.brown > > Anyway the gfp mask description and constrains for vmalloc are not > documented. I will add a new patch to fill that gap and send it as a > reply to this one > This is really good. People should be prepared for a case when it never returns back to a caller :) -- Uladzislau Rezki