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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D4DDC3DA7F for ; Tue, 6 Aug 2024 02:26:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A90196B00C2; Mon, 5 Aug 2024 22:26:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3F936B00C4; Mon, 5 Aug 2024 22:26:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DFEF6B00C5; Mon, 5 Aug 2024 22:26:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 6F4CA6B00C2 for ; Mon, 5 Aug 2024 22:26:21 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 22F8F1204D2 for ; Tue, 6 Aug 2024 02:26:21 +0000 (UTC) X-FDA: 82420231362.23.9268431 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf09.hostedemail.com (Postfix) with ESMTP id ECD2C140009 for ; Tue, 6 Aug 2024 02:26:18 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dc+I1BSb; spf=pass (imf09.hostedemail.com: domain of jasowang@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=jasowang@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722911147; a=rsa-sha256; cv=none; b=d0WFZPD/gknmr0xa/53InUnLsp7hoE//Ftadkw1cVyTH9fjZKGS6HH6AEpnK8EL1z/LE4T qw/XO1kEgSWP7HW4p6LSGHhXb+hQ6LxfUhFKI3bTjhclFeIx9S2qxBQCY+gJ97HjrGEjeO whUrmF+GssE01vbOYer39DTQJ8bINsg= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dc+I1BSb; spf=pass (imf09.hostedemail.com: domain of jasowang@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=jasowang@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722911147; h=from:from:sender:reply-to:subject:subject: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:dkim-signature; bh=k6NTygJfYjeiDGiiM5Z7PFfl8zAiOPhgCZVHXHCb3mQ=; b=G75AXy4LcVS+F1Pl4BOIm3ey/0lvdMfEC6ncsBP6FLlSS1qLu6BKTjuwriB+oGBSYoGPXb wpt5qiO7VPpznX88ocJTsKkm+waYPxE33Gy9fUhLG44rYrJmEXH1juQt3zJYhDNDx0YecZ ACvJlPcw/aD6PberuXFwqfdexnojrQg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722911178; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=k6NTygJfYjeiDGiiM5Z7PFfl8zAiOPhgCZVHXHCb3mQ=; b=dc+I1BSbnIVrPn2hUZxov4pN9rvftI4y7qyJGL+dsrRlKlP2rcxRqK5PiepsHOJK5xKi+7 DDXRoy0RITkFVgnpbKWYGvQaFCrdq75DUsyTUCn1GrAOHHc597gZG/4Uq4tn/u9MaUxj0u J3v/Cnyl/s1Ib+ae2xfhrir/vQdKBxQ= Received: from mail-pf1-f200.google.com (mail-pf1-f200.google.com [209.85.210.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-582-_Zq35VXwNritYZcVFjgYGg-1; Mon, 05 Aug 2024 22:26:14 -0400 X-MC-Unique: _Zq35VXwNritYZcVFjgYGg-1 Received: by mail-pf1-f200.google.com with SMTP id d2e1a72fcca58-70d1831ae05so185606b3a.1 for ; Mon, 05 Aug 2024 19:26:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722911173; x=1723515973; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=k6NTygJfYjeiDGiiM5Z7PFfl8zAiOPhgCZVHXHCb3mQ=; b=aviqU8I8Niow7tQwwPUxc57yl0gVcmvF+ZbI/yqv/knPBAcdWA+rc2k2o+gcZcxYSY HhQtd88AYe5QNZ3KoPYlurBmUafjLo5i678KI/h3w1Vy2DseHAhiZIiWJZRiYwEeonNv nmqvet12XjY2KunsE+9GtKhbMi3eSjCuP2g+1MeHXcE3Zne3RfKroEk+AxmtMVDg0jXx f+xxIPH7V7nhKZdGZzrbsB7HbJ0JHAdeHn0GDuH4CuCshyJ+QV8etKUsQLy5jjvGFbf5 AOtidUQiazMtpo7SiVpkhWb+hgi37c5bwKCWfPmtpy3+iv3jcSL2hXJduVIM7sFrIYLU 2rpw== X-Forwarded-Encrypted: i=1; AJvYcCUP6A1WuK3dMyXJTJ4P2xEnx9CnBm/FLMjdvw941cfsCGpq5Dqt/CPNT3bgJphneIbNHUvQCK0VWBRotVFk9NCfopA= X-Gm-Message-State: AOJu0YzS/WhiOY5vsI8qbzSwNMNwkwxSBDo+z1me/mf+Vr30tLOmiqNw XP5pzO6JLOVatRaE0+Qb7Oy/yX0sjOVmPVOdnkQm1QrDj1m0QDHuHP5BBUziacT31mRMQzCkUtd pl/FtoYVRDmfAzXsNLbSUb/6CMBElERVjKaNPtJ1oCqoqyxW0FTGntfcyJorGPRHBCakzmS/KuJ aYPehP1ltbVupimmdIJjT2cIE= X-Received: by 2002:a05:6a20:72a6:b0:1c0:e612:296d with SMTP id adf61e73a8af0-1c6996a03e4mr18761549637.54.1722911173006; Mon, 05 Aug 2024 19:26:13 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEfuGebwST7wXEt/UP+32zeyEU8M+cGevEYOCeQzf+mp8OawI/DOWjnqYlnHzgC5I4WJomU0+EyO3jX+bhI4VE= X-Received: by 2002:a05:6a20:72a6:b0:1c0:e612:296d with SMTP id adf61e73a8af0-1c6996a03e4mr18761531637.54.1722911172504; Mon, 05 Aug 2024 19:26:12 -0700 (PDT) MIME-Version: 1.0 References: <20240805082106.65847-1-jasowang@redhat.com> <20240805042421-mutt-send-email-mst@kernel.org> In-Reply-To: <20240805042421-mutt-send-email-mst@kernel.org> From: Jason Wang Date: Tue, 6 Aug 2024 10:26:01 +0800 Message-ID: Subject: Re: [PATCH] vduse: avoid using __GFP_NOFAIL To: "Michael S. Tsirkin" Cc: xuanzhuo@linux.alibaba.com, eperezma@redhat.com, maxime.coquelin@redhat.com, xieyongji@bytedance.com, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, 21cnbao@gmail.com, penguin-kernel@i-love.sakura.ne.jp, linux-mm@kvack.org, akpm@linux-foundation.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: mx69b1d9buewtkykyw6f3wuo7kxa8tcx X-Rspamd-Queue-Id: ECD2C140009 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1722911178-105528 X-HE-Meta: U2FsdGVkX1/6QwGzIkD98SPAN+hgjcP0M1aGCFNHaRwTmik9x//Ub8gdlQ/F46b3443BpeMybS775qSSK1ZEHxy3lNbij8YpyBM/GSbtf7Oq7OQbB5ILZaS/n+1VePD2C2EFLHnani0emX6UglATlITmmvpAjU/y/oI5ct+0QJtmwUh8HOKUw/SPIJvSTSnJr5jLZfrk61w29RYIrA3S2RiplhL3RneU/WeP+bXGz+rynYFiIiqoeON+DyHawHo28tKiP//j3zEky3h6tbjKX1EswgWz67vw3E/2WLLX09cnpTjDT8dip05Ej6O08uo5DQ7knP4VnU2H4gPNYcqlyFFDdENz2gsTN3t1c3s+M20RF4p9uj6nwtmWfh87YjJpv1XklxZ7TI9bHERC6lTl3FaOXflSKU5XFoksNQRQAMmLbn2XBnuo9sjjwo+WesX8jRxQFOfYta72vpf0SUHntRGS32bybQqE6uOsdkf87hpuOB/leFmpcERtXQzTKSDBjFLRlkAyewgpy5pRNtjgwyOj8RCQqOCaPdsKBbAHkdDDIjjA3KR33qvHmBd9+QluAdK/hapKe+xVp3+BKy+z52eOe2yG8vAIxcJz8n/bxeFBGTCbT31SlAchYXg8mD4IqLgDCGnef3i3AdXeKw4gP9PgTvA51RKu/MDnJ0KxmyPGbzH22ejnJjx/6i7bP+Av1MIHaOKgKxQ18FihW2U7uq88X//z29upE6sxzdnktz1Kt4BQdcvvLLEumgXcNe2558msAZmG1DRGAUpiQCAWhf49fJhaqVWz4Vf9Gcn7yy/8V4MpyFVqqPJfW6P+b8ZOjoY3oV0dhZCphKljT9LSU0z9rkNPFBEg4/h7GXBx1YZEi6g460LCEPSJ2x+ay+xUSmkbyWFRFusFeOD+NlmD8Mc8CrJZqtQT3MmAEh8t3FWHs5URnDmvlMm5nT024MN+0fuG6eNlMOYDtzvRcq+ R48kHxBQ QEqcbQb1DZK8dcys76tjU9MPBZ1VSMV0eNue7ZkOt+0VhzqFJZ2vUcQ6jGXbVSBuEinRLHhb7q/cC8YxkSrwiFom2erM+bjbJGvAxsdUfFVVE1TFIbWcsogpxI38qTFbkmTH135ZY1MvmgGreXOnY8q+thDTpwisc5B2CKUrBgL2Q3vhG8a/N2AzIXSHjYi2L7GarZaWBMgA5l8KbjU/xrlhYBOIzWRE0zJHtLHC/xkCUfOnGAPdxiXwANC9vCrwhlQVcnixOVndwKB/Amvvz/yHkyNIabecY1DG3B3mOb3LZTOs= 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: List-Subscribe: List-Unsubscribe: On Mon, Aug 5, 2024 at 4:26=E2=80=AFPM Michael S. Tsirkin = wrote: > > On Mon, Aug 05, 2024 at 04:21:06PM +0800, Jason Wang wrote: > > Barry said [1]: > > > > """ > > mm doesn't support non-blockable __GFP_NOFAIL allocation. Because > > __GFP_NOFAIL without direct reclamation may just result in a busy > > loop within non-sleepable contexts. > > ""=E2=80=9C > > > > Unfortuantely, we do that under read lock. A possible way to fix that > > is to move the pages allocation out of the lock into the caller, but > > having to allocate a huge number of pages and auxiliary page array > > seems to be problematic as well per Tetsuon [2]: > > > > """ > > You should implement proper error handling instead of using > > __GFP_NOFAIL if count can become large. > > """ > > > > So I choose another way, which does not release kernel bounce pages > > when user tries to register usersapce bounce pages. Then we don't need > > userspace > > > to do allocation in the path which is not expected to be fail (e.g in > > the release). We pay this for more memory usage but further > > what does "we pay this for more memory usage" mean? > Do you mean "we pay for this by using more memory"? Yes. > How much more? Depends on the workload, but basically, it's just the maximum size of bounce buffer: Default size 64M #define VDUSE_BOUNCE_SIZE (64 * 1024 * 1024) Maximum 1G: #define VDUSE_MAX_BOUNCE_SIZE (1024 * 1024 * 1024) Thanks