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 97B0DC433EF for ; Wed, 20 Oct 2021 14:30:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 48639611B0 for ; Wed, 20 Oct 2021 14:30:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 48639611B0 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 D898D6B0071; Wed, 20 Oct 2021 10:30:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D12176B0072; Wed, 20 Oct 2021 10:30:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB2E16B0073; Wed, 20 Oct 2021 10:30:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0141.hostedemail.com [216.40.44.141]) by kanga.kvack.org (Postfix) with ESMTP id A79686B0071 for ; Wed, 20 Oct 2021 10:30:57 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 4F7732D24C for ; Wed, 20 Oct 2021 14:30:57 +0000 (UTC) X-FDA: 78717052554.29.8ED7DE5 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) by imf25.hostedemail.com (Postfix) with ESMTP id CD988B000183 for ; Wed, 20 Oct 2021 14:30:51 +0000 (UTC) Received: by mail-ed1-f42.google.com with SMTP id d3so27691880edp.3 for ; Wed, 20 Oct 2021 07:30: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=iFAwf1Gu+ZBiSW1CPvj4L0uWy2D/0RqhKLQHFsLSUs8=; b=EWotqfG/a7IlHyHxzfO3IlJLzDf3b0K6lOYL+cxy84J+m/sr9lXC2gmL8ASPIphDhB a0FxJKhe1yt/qWjukMgg1kyE2MOoH3jPt+G2uKtlYo5RAYK1Ut/RT0rU4XUreflUQd+Q HC5PCXHYr8QgSZyT19rQyw53al0QucB3wxp70xgOTgI7ULOKA0YlP41uSdGWOuHqRsHL 1VIB2mxBqdmHUVZQQrI4Ko5QyPb9IMHpqoitpJkHVYF56naYmfbBhDWezJ5vOWrhyVct EMrqO7WFk3utTJ67IEn7PT7ku00ZbEkYOKQNtlDFrEqzZg5rtJ0x/qvqESmAu8ZwKFv3 m3TA== 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=iFAwf1Gu+ZBiSW1CPvj4L0uWy2D/0RqhKLQHFsLSUs8=; b=GjmKOQRuC0+8bUssmmxVNKe+tpwerioLP7Q7uxj3CUihUrXkPzrWn1wZSVD4uP9SII C8Rdh4E9VUqz1IMVHg2UCLv5fGyc6VNKm/7a7AffXQYDv845D9bO77mGYoCT3Rjv3zMI G3x4jVmB/SDSFYH3/q29S4bEEzRwmnE9EnZm8rS5PZt/b3TtsLm1GNEzyi0NHGHDAs5z tQFovBnFmV6DdrFUwTMqVFWGpisMkU+Vh9VMlXUZhTvhtE/tIErZpqImjRHhTgOd8f0x f1Le7Ij8PC3A+oisY7MqVuVpurMP7D/LkP8SNNv0gffwzRg7wpWE8zEw78GSZYK6c/Id xatg== X-Gm-Message-State: AOAM533f2IPVHPJHPWgLBBLqd9c6Qcf2bVZD0w0igEcByAhe2eSQPS1U 3g1yvS7RnEht6mQr1O6vEi2oU9TNcM0Tk9F/QwA= X-Google-Smtp-Source: ABdhPJwCa3TZeYsIQ2sAMttfKhqN3NLqsHmP68L6+eiUiFfr79Mg0tsKGFRs5QqAtWGxtFxc6woGdKg8hI4xr0F5NL8= X-Received: by 2002:a05:6402:22d6:: with SMTP id dm22mr367043edb.209.1634740165899; Wed, 20 Oct 2021 07:29:25 -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 16:29:14 +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: CD988B000183 X-Stat-Signature: x4utsx5tp5gbiq4c1ssgk9jxmkaqsw65 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="EWotqfG/"; spf=pass (imf25.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.42 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1634740251-830086 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 Wed, Oct 20, 2021 at 4:06 PM Michal Hocko wrote: > > On Wed 20-10-21 15:54:23, Uladzislau Rezki wrote: > > > > > > > > > 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. > > Yes, but there is no explicit event to wait for currently. > > > 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 I've said I am OK with either of the two. Do you or anybody have any > preference? Without any explicit event to wake up for neither of the two > is more than just an optimistic retry. > >From power perspective it is better to have a delay, so i tend to say that delay is better. -- Uladzislau Rezki