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 EC977C433EF for ; Thu, 21 Oct 2021 22:49:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7788B60F9F for ; Thu, 21 Oct 2021 22:49:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7788B60F9F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id DE25E6B0071; Thu, 21 Oct 2021 18:49:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D91636B0072; Thu, 21 Oct 2021 18:49:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C8017900002; Thu, 21 Oct 2021 18:49:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0128.hostedemail.com [216.40.44.128]) by kanga.kvack.org (Postfix) with ESMTP id B923F6B0071 for ; Thu, 21 Oct 2021 18:49:18 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7B40832625 for ; Thu, 21 Oct 2021 22:49:18 +0000 (UTC) X-FDA: 78721937196.07.AC721BE Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf24.hostedemail.com (Postfix) with ESMTP id D759EB0000A9 for ; Thu, 21 Oct 2021 22:49:14 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 58C141FD59; Thu, 21 Oct 2021 22:49:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1634856556; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mDHpYnkAmFo9eAjY7AwXYlbZAwsJIRr7JJORcjSJYRU=; b=CmOCnn/AiuATNEW2VSzj1lAxvxbWDn4ardHPbAFskt5IPX90UEq7RPgIuYAHYlhhAaM4JL pjtJa/qir67yFr/1B533YbK6Al6xdqXQO4cYp85+8lUsK18ExW0nOxQ1ropobeYcBQuJHn lKfhT0KZqR5q3VAJ2dFTr6k+yeS6DkI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1634856556; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mDHpYnkAmFo9eAjY7AwXYlbZAwsJIRr7JJORcjSJYRU=; b=8z1v2qM3jIuqVdl3kbTNQzzuPodV0NqyXgNSzwNSvsCJaJMYHDnKl1kwZ2/RzAGdnmFPN6 n6hXkcQFQt21BIAg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 72DF413BEC; Thu, 21 Oct 2021 22:49:12 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id ziSsBmjucWHJdQAAMHmgww (envelope-from ); Thu, 21 Oct 2021 22:49:12 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "NeilBrown" To: "Uladzislau Rezki" Cc: "Michal Hocko" , "Uladzislau Rezki" , "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 In-reply-to: <20211021104038.GA1932@pc638.lan> References: <20211019194658.GA1787@pc638.lan>, , , , , , , <20211020192430.GA1861@pc638.lan>, <163481121586.17149.4002493290882319236@noble.neil.brown.name>, , <20211021104038.GA1932@pc638.lan> Date: Fri, 22 Oct 2021 09:49:08 +1100 Message-id: <163485654850.17149.3604437537345538737@noble.neil.brown.name> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D759EB0000A9 X-Stat-Signature: eo57pzycg5z466zzcmnj8ad36tm6earr Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="CmOCnn/A"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=8z1v2qM3; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf24.hostedemail.com: domain of neilb@suse.de designates 195.135.220.29 as permitted sender) smtp.mailfrom=neilb@suse.de X-HE-Tag: 1634856554-700182 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 Thu, 21 Oct 2021, Uladzislau Rezki wrote: > > On Thu 21-10-21 21:13:35, Neil Brown wrote: > > > On Thu, 21 Oct 2021, Uladzislau Rezki wrote: > > > > On Wed, Oct 20, 2021 at 05:00:28PM +0200, Uladzislau Rezki wrote: > > > > > > > > > > > > On Wed 20-10-21 16:29:14, Uladzislau Rezki wrote: > > > > > > > On Wed, Oct 20, 2021 at 4:06 PM Michal Hocko = wrote: > > > > > > [...] > > > > > > > > As I've said I am OK with either of the two. Do you or anybod= y 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. > > > > > > > > > > > > I am a terrible random number generator. Can you give me a number > > > > > > please? > > > > > > > > > > > Well, we can start from one jiffy so it is one timer tick: schedule= _timeout(1) > > > > >=20 > > > > A small nit, it is better to replace it by the simple msleep() call: = msleep(jiffies_to_msecs(1)); > > >=20 > > > I disagree. I think schedule_timeout_uninterruptible(1) is the best > > > wait to sleep for 1 ticl > > >=20 > > > msleep() contains > > > timeout =3D msecs_to_jiffies(msecs) + 1; > > > and both jiffies_to_msecs and msecs_to_jiffies might round up too. > > > So you will sleep for at least twice as long as you asked for, possible > > > more. > >=20 > > That was my thinking as well. Not to mention jiffies_to_msecs just to do > > msecs_to_jiffies right after which seems like a pointless wasting of > > cpu cycle. But maybe I was missing some other reasons why msleep would > > be superior. > > >=20 > To me the msleep is just more simpler from semantic point of view, i.e. > it is as straight forward as it can be. In case of interruptable/uninterapt= able > sleep it can be more confusing for people. I agree that msleep() is more simple. I think adding the jiffies_to_msec() substantially reduces that simplicity. >=20 > When it comes to rounding and possibility to sleep more than 1 tick, it > really does not matter here, we do not need to guarantee exact sleeping > time. >=20 > Therefore i proposed to switch to the msleep(). If, as you say, the precision doesn't matter that much, then maybe msleep(0) which would sleep to the start of the next jiffy. Does that look a bit weird? If so, the msleep(1) would be ok. However now that I've thought about some more, I'd much prefer we introduce something like memalloc_retry_wait(); and use that everywhere that a memory allocation is retried. I'm not convinced that we need to wait at all - at least, not when __GFP_DIRECT_RECLAIM is used, as in that case alloc_page will either - succeed - make some progress a reclaiming or - sleep 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. Thanks, NeilBrown