From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 025BF364043 for ; Thu, 25 Jun 2026 07:47:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782373678; cv=none; b=CsANDfIdrLL7sH9VVOOrZO6gA0XQi0VXAJjr2/sOcc45HTh0iblExRFgQsl8Ngj5UPoANbZLp7tMDVZrPauAotq6UC44jzQISEPxn8k+Lv2Gdcb5rrDbz+WNI1JdTr1vrnuPIxGwu3Pmq5iQQWLuxb745J0BDlHutmnTSmeNp8U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782373678; c=relaxed/simple; bh=z6j/CYLCEGsu/XTwiHxCfONIIvqTs8qzrNl5rjDFYiI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=P5toAylv0qV+EsyM/usV+MYu90xzpDYjuL49ADaWemT0B1OuH4PSm94kit9KwYOOWcl+nh+/uw8zc1BooV9dCdnfopfiTtxFA0mPfdtgS21D1IvW3kjnN/dp8il0JRHBqYrKUgcfagfzoHJeziuT77CBgxyeQFFZ7s2O8r5eAyc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M8wc07r5; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M8wc07r5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 629371F000E9; Thu, 25 Jun 2026 07:47:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782373677; bh=6EWf8/p3GdUfDsB6KUh8cm6oeky3cDiDHBT1ngph3QY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=M8wc07r5i8ikZrrruBZSlFI6ZiEcpaVSmzn3OWpol0NLZBI1Z5CrNHFGkPnYt8ia6 0yRZLA+z+PrGz+DNu7N2dGurP12D8fqbDklIRoDMIN9MnxNb/xG0Qtr/CNTHLtfbMt k6qHkzc0mpZJz/fqQZxhuM5Yq2+j6xIx+HPfSJ1s8cq3H52rj7KUVdAdBCM9jDkGjy FrcHzCwya5a6S9SLixuV4k7yJP4ghsZbAlt1OGZaZJ6i1OmvfThZochaaQy9ttk8z8 MgX+UtezYFty2vTwI21NbzRz9Dz7CcjHmoAlN32+tOUYNGH+i+zPKnE5LqgpOT7dO1 Ndm0MibJax02g== Date: Thu, 25 Jun 2026 08:47:49 +0100 From: Lorenzo Stoakes To: "David Hildenbrand (Arm)" Cc: Rik van Riel , linux-kernel@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , Dmitry Ilvokhin , Borislav Petkov , Dave Hansen , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Suren Baghdasaryan , kernel-team@meta.com Subject: Re: [PATCH v2 0/3] mm: __access_remote_vm with per-VMA lock Message-ID: References: <20260625015053.2445008-1-riel@surriel.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: (Note that it's the merge window, really ideally you should be saving sending non-RFC series until after the merge window closes, none of these series will be taken yet and you'll have to resend anyway) On Thu, Jun 25, 2026 at 08:32:43AM +0200, David Hildenbrand (Arm) wrote: > On 6/25/26 03:50, Rik van Riel wrote: > > Sometimes processes can get stuck with the mmap_lock held for > > a long time. This slows down, and can even prevent system monitoring > > tools from assessing and logging the situation, because they themselves > > end up getting stuck on the mmap_lock. > > > > However, with the introduction of per-VMA locks, we can improve the > > reliability of system monitoring, and generally speed up __access_remote_vm > > under mmap_loc contention, by adding a fast path that does not require > > the process-wide mmap_lock. > > > > This fast path is only compiled in and used when it is safe to do so, > > meaning a kernel with per-VMA locks, RCU pgae table freeing, the VMA > > is not hugetlbfs, iomap, pfnmap, etc... > > > > v2: > > - simplify the code, which should be ok because these copies are < PAGE_SIZE > > - clean up the code > > - fix locking wrt tlb_remove_table_sync_one() > > - hopefully address all the other comments This is really not sufficient :) you should break out the changes you make and who suggested them. If people give their time to review, you should take the time to make it clear you've dealt with it. > > You mean, ignoring my comments about not reiplementing GUP entirely? > > NAK Yeah agreed. As replied elsewhere, I don't think we need to do that anyway? But you _really_ need to respond to review inline so we can have those discussions and ensure that you're moving forward in the correct way. Just quietly resending with a catch-all comment as per above puts all the load on us to go and check that you've done what we've asked. On my side, my review time is very limited now, so triage dictates general dismissals when the series looks wrong, engaging in discussion will help us all move forward efficiently. > > -- > Cheers, > > David Thanks, Lorenzo