Received: by 2002:a05:7412:98c1:b0:fa:551:50a7 with SMTP id kc1csp376361rdb; Fri, 5 Jan 2024 12:58:30 -0800 (PST) X-Google-Smtp-Source: AGHT+IEGyHtRmqQOZ7Fc9OG1Avrto+D87aC9hhos88gifFhmcBwRLfDAAiMr5yc8CkoNNCM56APt X-Received: by 2002:a05:620a:4402:b0:781:30a0:3897 with SMTP id v2-20020a05620a440200b0078130a03897mr211929qkp.16.1704488310688; Fri, 05 Jan 2024 12:58:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704488310; cv=none; d=google.com; s=arc-20160816; b=fwSZCXZy8Gjs63kU1WVgDVCai9WR15bvH8TUH0Nr5pappvB0z6gdzyGMqBEPLolvGl mUMgZT4h2IYH80cFv50fw6DGGAmEnAn9WdO/2ZIx15QmNk4PNcNRz+RlfZcQ+Tenn3UR zjzHB5uJRiii/vLMQmoc0pNOSxrFAzuesREgbrPg3W6cpLblHGauMw06TqpsDhiEO73v KEahHdytFYm2R5V6+bcJb1sk0B1LaxqxsKYeg/CXfVWbzvB5tfZbzxgXUNCm0WNMTvJu aUmHT4sn92CEoxYyLtsXLe7bhziy+vxIKfbrIAIsXr7+qZeiz6trEhJCKbvwZQEbTBMJ +dkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=nMbzOtCbU7XTEYEKAv0oHU42nzHm9G0AGeV1eKduXTE=; fh=v3nbYGjL6GkiMc1PnuPIjI9v4orT3rlj9Wr/xOgpxl4=; b=MbSTbjuRCvu3vEdBZ12RljCGeymwNlLFSvnWQowIstVVJGtXHr9C748j6qw3relLIo pNcEVx/6jyh0yStQcF0eMssNmiGl7OYnxKk5HN7WkCk40J9NrLrFj5xYnxQ1ssmYOeyn Z63fuPP9umrXdJUNFcb/dcxtcsFndP7ftXTZUZYKmR422xmuzSCXbrwVKuhag7K2TNvY 7G9gqcWyfzF9DEAZfD96bzpv+eplJNArya6EHQABgWJ+ERy28vx718j16KsDq3OMJh7D NW5+sBewRcWUzDQAil4qBA4nG1mSN/W1tJlDsaJ0opX7W/TaAKuwFQAppq6BPya896En rfEw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=eztdRwfW; spf=pass (google.com: domain of linux-kernel+bounces-18358-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-18358-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id bj11-20020a05620a190b00b0078308162e72si2456236qkb.319.2024.01.05.12.58.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jan 2024 12:58:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-18358-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=eztdRwfW; spf=pass (google.com: domain of linux-kernel+bounces-18358-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-18358-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 71BE91C23298 for ; Fri, 5 Jan 2024 20:58:30 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 785C0364C8; Fri, 5 Jan 2024 20:58:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="eztdRwfW" X-Original-To: linux-kernel@vger.kernel.org Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC979364B5; Fri, 5 Jan 2024 20:58:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=nMbzOtCbU7XTEYEKAv0oHU42nzHm9G0AGeV1eKduXTE=; b=eztdRwfWypwC8xZv1BIq3Aciu4 jbIeY4xGqeV/+VMpk0imOJyKUbEyjm5LbIqY4YOXcENrdsYbkbu8okln45v3sYnCZHCbcW3WPSYwn totsqvt7HTbWbcy7WhB9rCMr+jrqRc4gpDGuJCNd/F3dgVhl4Su13eo9iS6FxhETKGFtGWc2NVK1h QxoAxQr5Pu7F8Dl1l4RIZXE28TGs4JxNkLtikhoDRvrVoKp4slfzg9AtThHPXfZAtMSx5bYlIcPmx eO1zZj5wzfVV+8HgXSqLKIizC/9P6Ufvnltk73WxrwhS8Esobha6s9kPYRCl8EkPQSGBd0fiVSlDR vgzUAmMA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rLrGN-001CKP-BM; Fri, 05 Jan 2024 20:57:55 +0000 Date: Fri, 5 Jan 2024 20:57:55 +0000 From: Matthew Wilcox To: Vivek Goyal Cc: Hou Tao , linux-fsdevel@vger.kernel.org, Miklos Szeredi , Stefan Hajnoczi , linux-kernel@vger.kernel.org, virtualization@lists.linux.dev, houtao1@huawei.com Subject: Re: [PATCH v2] virtiofs: use GFP_NOFS when enqueuing request through kworker Message-ID: References: <20240105105305.4052672-1-houtao@huaweicloud.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jan 05, 2024 at 03:41:48PM -0500, Vivek Goyal wrote: > On Fri, Jan 05, 2024 at 08:21:00PM +0000, Matthew Wilcox wrote: > > On Fri, Jan 05, 2024 at 03:17:19PM -0500, Vivek Goyal wrote: > > > On Fri, Jan 05, 2024 at 06:53:05PM +0800, Hou Tao wrote: > > > > From: Hou Tao > > > > > > > > When invoking virtio_fs_enqueue_req() through kworker, both the > > > > allocation of the sg array and the bounce buffer still use GFP_ATOMIC. > > > > Considering the size of both the sg array and the bounce buffer may be > > > > greater than PAGE_SIZE, use GFP_NOFS instead of GFP_ATOMIC to lower the > > > > possibility of memory allocation failure. > > > > > > > > > > What's the practical benefit of this patch. Looks like if memory > > > allocation fails, we keep retrying at interval of 1ms and don't > > > return error to user space. > > > > You don't deplete the atomic reserves unnecessarily? > > Sounds reasonable. > > With GFP_NOFS specificed, can we still get -ENOMEM? Or this will block > indefinitely till memory can be allocated. If you need the "loop indefinitely" behaviour, that's GFP_NOFS | __GFP_NOFAIL. If you're actually doing something yourself which can free up memory, this is a bad choice. If you're just sleeping and retrying, you might as well have the MM do that for you.