Received: by 2002:a05:7412:98c1:b0:fa:551:50a7 with SMTP id kc1csp388874rdb; Fri, 5 Jan 2024 13:27:37 -0800 (PST) X-Google-Smtp-Source: AGHT+IFP+sAQUarllqKsUIQI4dWoMTvdvLINk44+DDHrKbbEf/hIHB6NKh1PsKOVrjeg29TjrD47 X-Received: by 2002:a17:902:ea08:b0:1d3:c5d1:8340 with SMTP id s8-20020a170902ea0800b001d3c5d18340mr3914738plg.22.1704490056941; Fri, 05 Jan 2024 13:27:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704490056; cv=none; d=google.com; s=arc-20160816; b=raomamEE1WQ2b7YojNezj3jkr9Vn7bXyQuVz19T+Jod09wfffYj892njkLWEIsLOJQ kMz13QIwWreayCFRB0U8c6RMNZOZtw9VWN9hj0Y1q0tBUoDul4JolZSsvt8zHtS2bpow i3bCfbbxR5aibQpv5WZGW9JzRoRo3vhErohEasp7rTaHZ+XB2ERNDStrQDTKE1plrICd fVCl28s6WHkqhgjK0k/XVKu74O30MdfsKkvdc20FHNbEKgRIe6X7HEcVB17VByHZslH/ VdwOD+kWodOqskInYxXGKayGRBkEh5b0v4961y5b5nSbHcL1nTK0o0zcYLpxZ38mzTRA 2wjQ== 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=nvKoTY7AaklNgqFAKz7HE/SEnOyTG3mvRlAEYCQEh+w=; fh=ZiQsjyLNcKyHswrAhUjMPAa4zxuCSv0az/kyHVVolcc=; b=iZdNEthC0dx6KJVL7ey58pjybWxeUGH2lHcbwnLlTKdbjde5a24k2BC/a/gItrljAQ 5HzbzvN7tiI9KQWuZfy3Jlhmq2o3Pv77UlzcxTjCtyG60xnKVOblOkfUjcsgQrOB1ATe Eph7gz8eXskvdS4FPRFv9cTIUXrSV4V1XIYYyr0d6kARZo/ggL9aiZtyyB3p/kw51bZd zgHGcvvKauaUcy9rK79JpFiRbspIEtKXvnTXdM+aGefe8NxGqG36y1W6tvMpetsA3e5r Op6tAE0IRKxr3t0XlrZ+up+m1N+iy6utyMjB6ayiM+HXUK2WQmqZfFxeLCnGMFUZ6E+N FTNQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gdIXVjlq; spf=pass (google.com: domain of linux-kernel+bounces-18367-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-18367-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id y20-20020a170902ed5400b001d3f68db02asi1762757plb.120.2024.01.05.13.27.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jan 2024 13:27:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-18367-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=gdIXVjlq; spf=pass (google.com: domain of linux-kernel+bounces-18367-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-18367-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com 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 sv.mirrors.kernel.org (Postfix) with ESMTPS id 9AFFD284943 for ; Fri, 5 Jan 2024 21:27:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3C6E9360B5; Fri, 5 Jan 2024 21:27:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="gdIXVjlq" X-Original-To: linux-kernel@vger.kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 F1CEB360A8 for ; Fri, 5 Jan 2024 21:27:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1704490035; h=from:from:reply-to:subject:subject: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=nvKoTY7AaklNgqFAKz7HE/SEnOyTG3mvRlAEYCQEh+w=; b=gdIXVjlqlNDYFMGmbccXVa6qDxRJxLQczrzueTli+nPako1Qw3SEYkm/VoGE3buJFbt2Lv gZtGByIjWiX4b+noD8MCY6K+JA9qkAllUQCTny5cvg8ozuIKKaQroDpIx96dNwZgbZLXFD PkjULTEFIDvkfjqJVFafXp1OWUdg6x0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-211-KlLuGbKbM9yD6Qvgmfd9VQ-1; Fri, 05 Jan 2024 16:27:10 -0500 X-MC-Unique: KlLuGbKbM9yD6Qvgmfd9VQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 19578837184; Fri, 5 Jan 2024 21:27:10 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.22.8.247]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A668D1121306; Fri, 5 Jan 2024 21:27:09 +0000 (UTC) Received: by fedora.redhat.com (Postfix, from userid 1000) id 0137E28EBE7; Fri, 5 Jan 2024 16:27:08 -0500 (EST) Date: Fri, 5 Jan 2024 16:27:08 -0500 From: Vivek Goyal To: Matthew Wilcox 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: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 On Fri, Jan 05, 2024 at 08:57:55PM +0000, Matthew Wilcox wrote: > 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. I probably don't want to wait indefinitely. There might be some cases where I might want to return error to user space. For example, if virtiofs device has been hot-unplugged, then there is no point in waiting indefinitely for memory allocation. Even if memory was allocated, soon we will return error to user space with -ENOTCONN. We are currently not doing that check after memory allocation failure but we probably could as an optimization. So this patch looks good to me as it is. Thanks Hou Tao. Reviewed-by: Vivek Goyal Thanks Vivek