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 57FFDC433EF for ; Mon, 25 Oct 2021 14:56:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DBC3260C40 for ; Mon, 25 Oct 2021 14:56:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DBC3260C40 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 433B9940008; Mon, 25 Oct 2021 10:56:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E3E4940007; Mon, 25 Oct 2021 10:56:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D35E940008; Mon, 25 Oct 2021 10:56:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0120.hostedemail.com [216.40.44.120]) by kanga.kvack.org (Postfix) with ESMTP id 1AE07940007 for ; Mon, 25 Oct 2021 10:56:33 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B89A319253 for ; Mon, 25 Oct 2021 14:56:32 +0000 (UTC) X-FDA: 78735261024.24.3EA4F2E Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf28.hostedemail.com (Postfix) with ESMTP id 31C5D90000A9 for ; Mon, 25 Oct 2021 14:56:32 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id D4790218B0; Mon, 25 Oct 2021 14:56:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1635173790; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OtqiJHq8zuWsjUAFlcfMCqR4fr77OchepUlZR3e94fI=; b=FN3DSXPzbzFZ1eiR+q19iiK1WqL+9W76nWnCKbE6Hvy3HDswx3rxfnRvM0rUOvzxxXhjxy /V8l8UsXuSr9ov5xT+zTwWT5SZ8a8OMyixDCTP3+pATodSk7lVG+2IvA6xTqAu1+iSeCht G9t9RANQ3TdzT0GPUkBZ7Vepwqq6H0o= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id A2EB1A3B8A; Mon, 25 Oct 2021 14:56:30 +0000 (UTC) Date: Mon, 25 Oct 2021 16:56:28 +0200 From: Michal Hocko To: Uladzislau Rezki Cc: NeilBrown , Linux Memory Management List , Dave Chinner , Andrew Morton , Christoph Hellwig , linux-fsdevel@vger.kernel.org, LKML , Ilya Dryomov , Jeff Layton Subject: Re: [RFC 2/3] mm/vmalloc: add support for __GFP_NOFAIL Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 31C5D90000A9 X-Stat-Signature: m4a3wzrdrynno8yidhofijzwa41nd8z6 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=FN3DSXPz; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-HE-Tag: 1635173792-404909 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 Mon 25-10-21 16:30:23, Uladzislau Rezki wrote: > > > > I would really prefer if this was not the main point of arguing here. > > Unless you feel strongly about msleep I would go with schedule_timeout > > here because this is a more widely used interface in the mm code and > > also because I feel like that relying on the rounding behavior is just > > subtle. Here is what I have staged now. > > > I have a preference but do not have a strong opinion here. You can go > either way you want. > > > > > Are there any other concerns you see with this or other patches in the > > series? > > > it is better if you could send a new vX version because it is hard to > combine every "folded" Yeah, I plan to soon. I just wanted to sort out most things before spaming with a new version. > into one solid commit. One comment below: > > > --- > > commit c1a7e40e6b56fed5b9e716de7055b77ea29d89d0 > > Author: Michal Hocko > > Date: Wed Oct 20 10:12:45 2021 +0200 > > > > fold me "mm/vmalloc: add support for __GFP_NOFAIL" > > > > Add a short sleep before retrying. 1 jiffy is a completely random > > timeout. Ideally the retry would wait for an explicit event - e.g. > > a change to the vmalloc space change if the failure was caused by > > the space fragmentation or depletion. But there are multiple different > > reasons to retry and this could become much more complex. Keep the retry > > simple for now and just sleep to prevent from hogging CPUs. > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index 0fb5413d9239..a866db0c9c31 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -2944,6 +2944,7 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, > > do { > > ret = vmap_pages_range(addr, addr + size, prot, area->pages, > > page_shift); > > + schedule_timeout_uninterruptible(1); > > > We do not want to schedule_timeout_uninterruptible(1); every time. > Only when an error is detected. Because I was obviously in a brainless mode when doing that one. Thanks for pointing this out! -- Michal Hocko SUSE Labs