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 A7C52C3DA4A for ; Mon, 5 Aug 2024 08:24:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A6426B008C; Mon, 5 Aug 2024 04:24:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 32F1E6B0092; Mon, 5 Aug 2024 04:24:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1AA2A6B0093; Mon, 5 Aug 2024 04:24:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id EDA676B008C for ; Mon, 5 Aug 2024 04:24:12 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 72894A7DAB for ; Mon, 5 Aug 2024 08:24:12 +0000 (UTC) X-FDA: 82417504344.30.2CBD96C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf09.hostedemail.com (Postfix) with ESMTP id 5992E140010 for ; Mon, 5 Aug 2024 08:24:10 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bN0DA2vy; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf09.hostedemail.com: domain of jasowang@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=jasowang@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722846200; a=rsa-sha256; cv=none; b=a4BSSbwu29R1SNL+J8nrUX3PCzsWBohsoK7N9Pmb7h+lGuWIOTt2itIFPMTVAvIk4wnoVE yCrm4Mv61UxEsVU+3BeQwU7dIzR8q+A5Rj3Fo5tY/wKu8qkCzwy1MTw7vozhO0OkPtIWhg RaKEkuM8kAjH1zN2TOF8h6sNCcRI5fI= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bN0DA2vy; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf09.hostedemail.com: domain of jasowang@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=jasowang@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722846200; 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=MZC/JUb0Bd5ny5AOzMQmgwCXo1oUUPkAQl3rIxUYCGA=; b=O6sLEccygdUdKG9voEuRDKSlkZ++7ggQfJJJaY465whYKUC7Gw8O4tKy/phu99DlC0Daj1 ErO5itiGaEw8ICwJHsRwFO5Pf4xZ57wGNcfQPZ90VkHhSb7grLBb0u2WjSgf1nQt1Z6IcJ 7eBynjdqgC4m2qCU74BoGvrb+WAxBDk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722846249; 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=MZC/JUb0Bd5ny5AOzMQmgwCXo1oUUPkAQl3rIxUYCGA=; b=bN0DA2vy/umL/1s5x/nrMtqJjSmlcKWYnG4z96/HgmC/UFFKoJRQ2W4y58rBuw/cpTOOvQ 0XuQB9B3KgLX4wylo+6fPUiS7R623zG/JUGyLg4pFnat+2WvwaoZZyMN7w0q6Hh461zih3 R0VY6sO18FhSCoi9DtK5xW4vgFQaZHA= Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-651-0FXiRSfKOJqPewxZtyGuSg-1; Mon, 05 Aug 2024 04:24:08 -0400 X-MC-Unique: 0FXiRSfKOJqPewxZtyGuSg-1 Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-2cb512196c1so10317954a91.1 for ; Mon, 05 Aug 2024 01:24:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722846247; x=1723451047; 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=MZC/JUb0Bd5ny5AOzMQmgwCXo1oUUPkAQl3rIxUYCGA=; b=UC7ECAG5+HwHvd5nJxNXhERV0HF0dMgHbAl6aBX0hr5QW+fFUch/XZhcA+4msGjgJ2 jP9wZAXoiScp4jQrsmoiA10R31TRgoBx2KJSUh6eZ0JUx5jBZFNjRYnxN+1kA8bcfOMq arTiCqK9E6XzgTgirfYGqD48YkDn8H+7bz43uvE1D8KL3F2JrGCPYv2hkEgRZcKdzfz0 C/VZG2zhD74rxKSsk/AoYs4+6pxyQi6D1iTWaKHPCDSmN+y+qe920/lAgQLIsvsGTL9J 4PbFoM5bVU9jWa/vQpOg8i5yHyYqtLNBkWsXPB+AGcTRl1VPnBVvbKdtiQ/Vpt2Qv38k 8crg== X-Forwarded-Encrypted: i=1; AJvYcCVxsO6ZhgoAaw5V3dGzkhvHPA9uO8m4AB1RDr3CMuztHtbekAxz810pvYcfnbTFXpqfcCV8CdWpD/WeK0GI7s1ghBI= X-Gm-Message-State: AOJu0Yy2ms/e+VUgEDTGlSbLuAJH2CGxBmVq38k/ejg/9XvzdP//JRnm E3bQ6SqSa7Zk3CsLXUlvbIEoWHXE4ikKURZqn1d07FkBXM3yl1QQGr7af/hL3Jlly+t84TEJOEk xQ2MsAZjMme//NrddhYMD0W7NpLZvPVEIjiEgHT5xbBIeZXpT9zgk5PdxAIQMwsSmK9pYwGfG8q 2Ufzx7rbCTdgswU/4blhqJFXo= X-Received: by 2002:a17:90a:7846:b0:2cf:c2df:67de with SMTP id 98e67ed59e1d1-2cff93c59f0mr9462389a91.9.1722846246917; Mon, 05 Aug 2024 01:24:06 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHOSNr/tffEf9orQJMuzIpDgMZ45fJMrYavKup4rOkDBdZro389KPHkDEY8ZwIfz9x8bfEImYDLvFDJMKuW2qw= X-Received: by 2002:a17:90a:7846:b0:2cf:c2df:67de with SMTP id 98e67ed59e1d1-2cff93c59f0mr9462370a91.9.1722846246368; Mon, 05 Aug 2024 01:24:06 -0700 (PDT) MIME-Version: 1.0 References: <20240805082106.65847-1-jasowang@redhat.com> In-Reply-To: <20240805082106.65847-1-jasowang@redhat.com> From: Jason Wang Date: Mon, 5 Aug 2024 16:23:54 +0800 Message-ID: Subject: Re: [PATCH] vduse: avoid using __GFP_NOFAIL To: xieyongji@bytedance.com Cc: maxime.coquelin@redhat.com, xuanzhuo@linux.alibaba.com, jasowang@redhat.com, mst@redhat.com, eperezma@redhat.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-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 5992E140010 X-Stat-Signature: 9zphxqg4xwbujitpewou7fa3toa8o954 X-Rspam-User: X-HE-Tag: 1722846250-795663 X-HE-Meta: U2FsdGVkX1/LA7mlrukzrYbvmPmueFI3nONKr5r2d1cdOhnEgvgUmkn7CtiOrq5K6JTklwjpVd0/JJwkbQ7TnieDHXs1suL5Byj1CXARviWihCOkJyffp3BhLQd+t2Jjrt86JJO9kPT+K5H9UWIxyaFIhr0YHqMYy4qRO70bDKaHWEEEPhjxF+iXtSezp3SlzY3+6A7DxjisI3Q8O5Z0a1u1NIcHOvMYpDifxLf8xI11XP8H9uithRdgcMgmq8DuUgfpd8uL7MUVrihQDxLesJ3IkU9EyXGkVx2d3MBPF41POsg+1M+IcuvwkAyAv7/jSiujAdAXJAKVyZspZD/zyOAappK0I4LngaHYz/iLbS+BPMrsc/aT3APTCN91aZOe2YDIdJkIEV+QxPXN/eCnrk9CdSDjvoxaByurvdfMbcV3DL5UqzsD+9MA6gmjWYUJddhewTG/bTljBLssLfexT8PnPL/Lk4VvSE4vLEGzxo/CCbf4RuaTcgEoCRkF1ptFbX8Ocnem0t4+CD3QbfgpqfYtiTJgf1BgNMXgqAP1RqYVSgnEFjhmC8+zTMKp3IsvCD81CETp8ogN0L6tAHN1LGbMbHedI2N0UdgXj+JWKx3z3wGdsz/XLKAMVEx/ilGOcNeOSsW9BJnIy++h+3NG//cZ86ccSHuxGTePLlP3P5AxR+QfjdjL4GGxa47RjTiB+hKAiJywcWbLPGVof5i4rw9KQ/z6u2QZcH9IV92CkPsMP6EA8DgpvHdNkfHGFyG4Uwtm4NCOkb1nyj/4fsxOU4xpZtk7O/hH9oJSAz7pujqOurkRv3s4KQyrKCDuk3YvIHd5g8zcRE4n1OjpMs3Cz5N9C+v/dLbc/+F++3H/yFFYMMM6mltGx02Wqp/t5RIWmbSi15DPFV4XBn1GYIdZFS22X8SQCOYnAMc9HJnkDhrP1XKI/EyLP50dOHNKii/Q8v7ea93HWUORVfsw0JN R8vJVNW9 6G4yeAoosf1JTw4tWByLFkC/NO3NBEdeny7eVZy4aK1606lekUnZoDCl5/qmiupHkagbOQmrvwcW3+mpuh8tdpEhOkNIkhUJ5AeQCqAUcn4S8t1v9dNigt5pA+iS5nGAYMBeqCLmMWsr3/9uRlUXT9ZVKd0o9Wzn4XPcbTzzBnAlLdqJxIF3ip2LbphzJBmlMgPtjFlSB3ZiWzZJ0crxFkr3YQYC1gsj80DUUYseTFwsVKpQ0yPXUuxKlp+uY0qEgnW2Skrxlk1vrjfpVe1ExNWxw+gY4kzTDnmHapqImeZObsFOXnqyFnwKesQbtJpGHx8KX4AqBeDCH35J7kSDuVqhaGkPWSuJEXhyUWTSiSm0udJ2x56SkHRa+Icw2zh/GXfsS 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:21=E2=80=AFPM Jason Wang wro= te: > > 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 > 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 > optimizations could be done on top. > > [1] https://lore.kernel.org/all/CACGkMEtcOJAA96SF9B8m-nZ1X04-XZr+nq8ZQ2sa= LnUdfOGOLg@mail.gmail.com/T/#m3caef86a66ea6318ef94f9976ddb3a0ccfe6fcf8 > [2] https://lore.kernel.org/all/CACGkMEtcOJAA96SF9B8m-nZ1X04-XZr+nq8ZQ2sa= LnUdfOGOLg@mail.gmail.com/T/#m7ad10eaba48ade5abf2d572f24e185d9fb146480 > > Fixes: 6c77ed22880d ("vduse: Support using userspace pages as bounce buff= er") > Signed-off-by: Jason Wang > --- Note for YongJi: I can only test it without usersapce bounce pages as neither DPDK nor libvduse users use that. Would you want to review and have a test for this? Thanks