Date:   Wed, 5 Jan 2022 20:53:39 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Daniel Jordan <daniel.m.jordan@oracle.com>
Cc:     Alexander Duyck <alexanderduyck@fb.com>,
        Alex Williamson <alex.williamson@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Ben Segall <bsegall@google.com>,
        Cornelia Huck <cohuck@redhat.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Ingo Molnar <mingo@redhat.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Josh Triplett <josh@joshtriplett.org>,
        Michal Hocko <mhocko@suse.com>, Nico Pache <npache@redhat.com>,
        Pasha Tatashin <pasha.tatashin@soleen.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Steffen Klassert <steffen.klassert@secunet.com>,
        Steve Sistare <steven.sistare@oracle.com>,
        Tejun Heo <tj@kernel.org>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        linux-mm@kvack.org, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [RFC 08/16] vfio/type1: Cache locked_vm to ease mmap_lock
 contention
Message-ID: <20220106005339.GX2328285@nvidia.com>
References: <20220106004656.126790-1-daniel.m.jordan@oracle.com>
 <20220106004656.126790-9-daniel.m.jordan@oracle.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220106004656.126790-9-daniel.m.jordan@oracle.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?80SOxbvCaIdOxg+RDfpQiXQzS948p20jlTcZvRekAYZkD0NZxCSbUf3Lqkfy?=
 =?us-ascii?Q?mUaKhhTnfLKQDiusWMojay6JiP/n1SjC5E+nv/melOjwIdsnjtOgySu160in?=
 =?us-ascii?Q?Q6DDi9WcCO/DEyHWASDwGm+q308UXp69Tq4c/C+9WgpKZDlMWNAea1FeCVs5?=
 =?us-ascii?Q?JrP6NBs/rr4nWKP60ttnQMjsmCVvas+98Q01T7BvkPTJgStA8ujWZFdYlJpa?=
 =?us-ascii?Q?xpZ8NHHC/r1OQoP10tW6WP7ND2UIyj9NoyVBXTJTqO1uWH9EnXDb9NHrEtW2?=
 =?us-ascii?Q?UM5Tbadu7HGnDQpZ9jyWWKlQHxrgqES+m55mft2fOWzB3vV5V0Tu7avJmn05?=
 =?us-ascii?Q?RE07JdDYHspa24X7V/Ia3cYZFkP/ZsnPc47veiNlTMvfAXf4vWjZrl2jJAUB?=
 =?us-ascii?Q?scj8TapqsF3PrxmvD9U9TbRVJI2EXmW6STk6hhOjWzSdDJexfhxQnL8ng9ps?=
 =?us-ascii?Q?R9AQHut+UXYb6NoRVLMAMPUGLe4nYFqopK6qFDlujBX0uPhWdazJtvaw/yqP?=
 =?us-ascii?Q?CyQMpJwjbN7jJ18lfXtk7t6IcopYDfScsAzjuVhaFSzRPXqDoQw/zu2gvlQd?=
 =?us-ascii?Q?aF8UezJ+L7hf+PPesneUYPJ9/e7gslVpRgUD6w9DlKrodqJvwgvbJ+9ihIWX?=
 =?us-ascii?Q?mNltgJi/MuAFkS8l6nCkjHZH174rl0YvnK1412YyyFP3ekzP7+uy8DRe/CIW?=
 =?us-ascii?Q?zQ9YIebUhpelCkpfFjP6LmNkCWlqWMbPj3DUeDiARs6p29O1sg/4+GzjeMoq?=
 =?us-ascii?Q?tu+zB3Bkt59cyNKkOuFEEkdaH7Mn0NQJg1syJRnN6VCyCqRAGVAhGlthEKZ1?=
 =?us-ascii?Q?GxCx9EOVx3SF+qLc/8fu54RnNljJkPh7DYOnb0nUKmikCEgoqGvZW0sJO3yh?=
 =?us-ascii?Q?vvainEhq685wHPEnohFhZnA5eRJgDy+wcQVfXjwYuiOGMAeiqq/9bmf3OB1f?=
 =?us-ascii?Q?K0UxGxyi3i1KgQ8nIMY4PDLGOoCmPjdOs5kVB4DvI+p2/iTwOMPBnyxQrofS?=
 =?us-ascii?Q?Ky0Vesv65yhdtsxBVgHaG72kPl0QdnFsqDvToDrjBvfMC7Pw/n3RhDeTgszu?=
 =?us-ascii?Q?OtrDCJ3xoE6R+/aiI2/tP3zFScc+N6yDns7V4QOzOlj3BEumeqyZ+a4aJqI/?=
 =?us-ascii?Q?tNm4sJwufCGCXreIboI4anHSDhw49BQB18VqtvW8MpMNLKF6s6MJL4xFxPUu?=
 =?us-ascii?Q?CqgErLY0StAzNj+WLbLOsV268CLQd52pVQM/Qs06vkd1kHYS9MItWrmyUkeH?=
 =?us-ascii?Q?dw58IuF0SCAOON2lcx3a3rgvLLtuwyYwVjaGN54LJHzqNXUF1Oz9aJ7rGYsg?=
 =?us-ascii?Q?Zv7q9uSv3EfhWNcVCsImbrNOaNqkYAG30z+D+RWTcmYi9Oss7683VChsG5Qk?=
 =?us-ascii?Q?tHzJfJ4hKR69xHqwumeqTl7p15ucMXyzwcICz1JUatnZrOsD2NiZo/Ju/Exj?=
 =?us-ascii?Q?LJPgHS6hIUVMRpgVQXIr6Pgu+8YvEV4W6auqQSbTXbU7HDfxK4fFiXHRKMFW?=
 =?us-ascii?Q?KpELZQPJmOep6iNktQX5j7iC482vMMF1HZkwQw0+HQXNKU0d27bJJbLA1+89?=
 =?us-ascii?Q?kttJc5JSmuDVcZMTtWI=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 032e89f2-67af-4dee-13cf-08d9d0aefc3e
X-MS-Exchange-CrossTenant-AuthSource: BL0PR12MB5506.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2022 00:53:42.7116
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: UFv0WdQEqmKEuhLdEGngorVroeRUprlceWjtgfVgKGk4ggK85YpfGb5s7swS/jZz
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR12MB5554
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On Wed, Jan 05, 2022 at 07:46:48PM -0500, Daniel Jordan wrote:
> padata threads hold mmap_lock as reader for the majority of their
> runtime in order to call pin_user_pages_remote(), but they also
> periodically take mmap_lock as writer for short periods to adjust
> mm->locked_vm, hurting parallelism.
> 
> Alleviate the write-side contention with a per-thread cache of locked_vm
> which allows taking mmap_lock as writer far less frequently.
> 
> Failure to refill the cache due to insufficient locked_vm will not cause
> the entire pinning operation to error out.  This avoids spurious failure
> in case some pinned pages aren't accounted to locked_vm.
> 
> Cache size is limited to provide some protection in the unlikely event
> of a concurrent locked_vm accounting operation in the same address space
> needlessly failing in case the cache takes more locked_vm than it needs.

Why not just do the pinned page accounting once at the start? Why does
it have to be done incrementally?

Jason