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 B2FF7C433F5 for ; Fri, 1 Oct 2021 22:46:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0A8DE61AEF for ; Fri, 1 Oct 2021 22:46:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0A8DE61AEF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 71A0A940153; Fri, 1 Oct 2021 18:46:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C997940121; Fri, 1 Oct 2021 18:46:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59152940153; Fri, 1 Oct 2021 18:46:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0217.hostedemail.com [216.40.44.217]) by kanga.kvack.org (Postfix) with ESMTP id 46D68940121 for ; Fri, 1 Oct 2021 18:46:08 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id EA2FA1812A470 for ; Fri, 1 Oct 2021 22:46:07 +0000 (UTC) X-FDA: 78649353174.23.A848D03 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf19.hostedemail.com (Postfix) with ESMTP id A4FD8B00046A for ; Fri, 1 Oct 2021 22:46:07 +0000 (UTC) Received: by mail-qt1-f172.google.com with SMTP id b16so10462407qtt.7 for ; Fri, 01 Oct 2021 15:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=tnXGytG/2aEvcazdaoXj71bXQnwjyukOXIDiPveIZXA=; b=pOTSnHYVXRz06VuaU1BDucThq3XLijVNOmqw8gUYgVjcX4bjaU1DPW80GPFpz1Bry3 5Izso0qtrLy+uxnjkbarKVIHYAhUgvRAYbABr2JkvP9GCyg+7YRvw6KqUUc7seGsa9fH KzDaVUI4r8DRENRxq0vwC8QCWDmKp8VauDJh3yS5lxyhzeb0C6mReZGMghzJA7mUDjLv 3H6R6bTZK2L5cSKTP/HRhXJP2RtP51MG45N0gotai5Ttri7QJaEBuKZ8DLCGMwehfYns QMf6evJgsJzNYeGrSyM/G3W4DM7LKIUGIRGLmulP3Gv60VEJqAsqbGSn5orZIQ0iTuZ9 WZEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=tnXGytG/2aEvcazdaoXj71bXQnwjyukOXIDiPveIZXA=; b=36hJe5qHmIISZ0keyi+Dok+Zlesn7UfXqUTcIMRcSsyw6okzmiLnZDbh8deMqZKhTw X3084ESf3xyN0qjNtW/hMlgcAW0XtBPbroAAmDAqR3BLpf7ykC+pGELxpjIS+hAtlGno jjqRa/9G1WRBGVj80j/Igsdge4EsUABeQRPjeZZg8hv0T+uqMleYo8wGOU0P9yykuDmF 6ucUAS+ll6rWopn0pKRGVOvLO8RdtoRlUmasHFyv4fmCQsT/YieiuvJbiQnyjZRwuuif OZJW1yd/UeydbOVGcwjkWhLLtPUb9XkqqEPdiRVUzW46tZQRuVoknqyWieU2ePSR5sC9 3ihQ== X-Gm-Message-State: AOAM530z4EZTh3ZSUd4GbLX5OmW6h0770F7SmeQUbS/6P9Rw7TbuLQaz cykgRnSDNzWugXsNpgJBCNGT3g== X-Google-Smtp-Source: ABdhPJwIsqD13TKJo7mm1SIikHRk6qEvBFD6JpS7ZAJB6SMruIQLkql7OpNf4qMoVFvzMVj7AMSNJA== X-Received: by 2002:ac8:7dc1:: with SMTP id c1mr551179qte.289.1633128366918; Fri, 01 Oct 2021 15:46:06 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id p187sm3759342qkd.101.2021.10.01.15.46.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Oct 2021 15:46:06 -0700 (PDT) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1mWRI5-009Y55-Ly; Fri, 01 Oct 2021 19:46:05 -0300 Date: Fri, 1 Oct 2021 19:46:05 -0300 From: Jason Gunthorpe To: Logan Gunthorpe Cc: Alistair Popple , Felix Kuehling , Christoph Hellwig , Dan Williams , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-block@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, iommu@lists.linux-foundation.org, Stephen Bates , Christian =?utf-8?B?S8O2bmln?= , John Hubbard , Don Dutile , Matthew Wilcox , Daniel Vetter , Jakowski Andrzej , Minturn Dave B , Jason Ekstrand , Dave Hansen , Xiong Jianxin , Bjorn Helgaas , Ira Weiny , Robin Murphy , Martin Oliveira , Chaitanya Kulkarni Subject: Re: [PATCH v3 19/20] PCI/P2PDMA: introduce pci_mmap_p2pmem() Message-ID: <20211001224605.GS3544071@ziepe.ca> References: <32ce26d7-86e9-f8d5-f0cf-40497946efe9@deltatee.com> <20210929233540.GF3544071@ziepe.ca> <20210930003652.GH3544071@ziepe.ca> <20211001134856.GN3544071@ziepe.ca> <4fdd337b-fa35-a909-5eee-823bfd1e9dc4@deltatee.com> <20211001174511.GQ3544071@ziepe.ca> <95ada0ac-08cc-5b77-8675-b955b1b6d488@deltatee.com> <20211001221405.GR3544071@ziepe.ca> <8871549c-63b5-d062-87ea-9036605984d5@deltatee.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8871549c-63b5-d062-87ea-9036605984d5@deltatee.com> Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=pOTSnHYV; spf=pass (imf19.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.160.172 as permitted sender) smtp.mailfrom=jgg@ziepe.ca; dmarc=none X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A4FD8B00046A X-Stat-Signature: qexrm63dgh7ornteb6pz3gimhwwor37b X-HE-Tag: 1633128367-530986 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 Fri, Oct 01, 2021 at 04:22:28PM -0600, Logan Gunthorpe wrote: > > It would close this issue, however synchronize_rcu() is very slow > > (think > 1second) in some cases and thus cannot be inserted here. > > It shouldn't be *that* slow, at least not the vast majority of the > time... it seems a bit unreasonable that a CPU wouldn't schedule for > more than a second. I've seen bug reports on exactly this, it is well known. Loaded big multi-cpu systems have high delays here, for whatever reason. > But these aren't fast paths and synchronize_rcu() already gets > called in the unbind path for p2pdma a of couple times. I'm sure it > would also be fine to slow down the vma_close() path as well. vma_close is done in a loop destroying vma's and if each synchronize costs > 1s it can take forever to close a process. We had to kill a similar use of synchronize_rcu in RDMA because users were complaining of > 40s process exit times. The driver unload path is fine to be slow, and is probably done on an unloaded system where synchronize_rcu is not so bad Anyway, it is not really something for this series to fix, just something we should all be aware of and probably ought to get fixed before we do much more with ZONE_DEVICE pages Jason