From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f68.google.com (mail-oa1-f68.google.com [209.85.160.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CA24B1DFE12 for ; Sat, 24 Jan 2026 15:55:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.68 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769270149; cv=none; b=h/NTxtMfyKBdYRgJMZcuUpd9lcUok2mHhyWWYFDUtvYmCgl1wLb5ZR3s5E86crnKqBFg0efm9z0q7Hhpqx8ycVWOIpFWqKEyHVjUxEKgH9u/dnwf5FUZMVKA0KvabXuOmo3JZ0CBztWuSGC6fEl0fycbTq8zLKopiEP6jWjlKiI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769270149; c=relaxed/simple; bh=U2+e4xKSAYRABwS2qCE3DaefmKfUoZiVs6WXlSlOT1U=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=PBVRruqXL8fMcWufqfWTJgSI2+N8TbrkToS4JaS8R8rw657jwR++/NilN5Pqwwx8iKkbXaPXh+KDrt3SdL6u9fFN3ZBzF7PmEGSWWw9Pe1boFmGrJfBwLqEg+UKjmvTEaCd/T7CrtsQ5Y3Sh8ZqbmgYHg3Utbk4zeDMUyuPn0Tg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk; spf=pass smtp.mailfrom=kernel.dk; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b=Pko0fuAe; arc=none smtp.client-ip=209.85.160.68 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.dk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20230601.gappssmtp.com header.i=@kernel-dk.20230601.gappssmtp.com header.b="Pko0fuAe" Received: by mail-oa1-f68.google.com with SMTP id 586e51a60fabf-4086661715cso2465270fac.2 for ; Sat, 24 Jan 2026 07:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1769270146; x=1769874946; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=b28I4oYFav6Da1zUgaoqh5wjH9PdZp3ISEmwrG28SHk=; b=Pko0fuAe2cq4uyqMVG0CzsaGKFA4qkVyf5TA6qrYTbQ2miDVXcvlxicQIRHiXRdMjO RKYNJ2ofkVCEVhQIAPaQH4TG9Uojmg4ZXVn13n4t2dU2zrUAymfC2wTX+dhcg7yZMV1f JFqMOWxyuDUZs71uuBPV+kEq4+z0xs5kxTb2liUuQoUya5XTtOMDwfOfIlk8VTs7CFr0 2ocpq//Qys+u7BilmV+4EOV+x3aIovX/jjkdZNm6XzaPbxQI5Sx+nnSb6w43sUGIt2md inYOYvzzBaCj9/h9Ri0/Adnez2+Mbv3Gpph+weMk3/ewpX7UgNKuKBveDoNnASWSHyoM K3TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769270146; x=1769874946; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=b28I4oYFav6Da1zUgaoqh5wjH9PdZp3ISEmwrG28SHk=; b=hTiaM2C0fInSqX0tfHzEFCSRTc+/aEyoZQk0eCBorjJHUvqA8sRrcwK73YGhcO1+is fCLWHp2RSMnBdDgsy4rCzpcIXAJw6GSjdzJPU7ya1vdtaJt45L4LiAYeJqD7frojjoB0 Q1YS3oO4cmmTUINGO8DCk20TbSW1l9y3DGaXK1tiFIUGHOE6WbWKT+AA1tQrrbevhZ8G sb/o2BZAuF6IISWylCDKWqcp+SEpC3hRIGJ55+QhPqY610I+4fBKaorOTn4CDbSN+pyk QhHR+Q3+ge+0TU7vD+M8R80jGwwACCoYeWhfXrv6z5QyJ7D7qZcQjZAU6y5J7Snnw0/0 eLEQ== X-Forwarded-Encrypted: i=1; AJvYcCVjlKy6SdKXjAfJf3JTKy0OuHTjY09RHEA/dolGLpShOf+3kOORL//sHBvsprbOyQ9orYYIgYf1VxQXW2c=@vger.kernel.org X-Gm-Message-State: AOJu0YwdhUqMaNFNcVihipHYbdEcOnHMH+8e6sTGkf1FIAlCHdPFHVt0 rypLRHhNbqfOgJw19Pgg7tbd5igooUBqoPJDMPCLnDrGIxvK7z6PwcbckEH/A+mlkns= X-Gm-Gg: AZuq6aJQyPst22Ky4XZe1aBSyDaAdckFyN/j5md+rHgdKQxDGWrMGoz9hlFMauQuB1x 6zOX0tOYTOn29bE5Mmoh/u6N5o6wylecC/PmbCkPl8MAcJw6PxbbYne8Ftr+kAREMbXqFALudB1 IYV0J3R6z8bGNThxDFb+7U/R7+ayPVi6b+HeL5RYkdQzwM60/y1Nie5/pMalPFR/hRatFPZmT7i AlXmWgKGQpPTbVPUe6pFfwVQwFh431494QJpB44becethQTS3m7g5X1fTayUpyPl0G2VAgekAbf zuwboi2RwFpLy0ynMEvR0tfHt1vYV44BVkm3dmsbxehYmO/nwaMqTSI3ZtE0YnEuC2bRp2sOGs7 MiLbECQLRxd7R3IKzuiKcys3nwqsiddeUEyeeN3dA08wR2LfNCc2OgAjWHNIzsPtJH1Lj695pnP /tE0WYck2MkIq3WU+onPJCOEifzqcdn2y3PYaWGma3Sl6CLLA1eXzmyIjTRMCr6YY6VZH/uA== X-Received: by 2002:a05:6870:d253:b0:3e0:9188:8f10 with SMTP id 586e51a60fabf-408bd516408mr2231166fac.0.1769270145077; Sat, 24 Jan 2026 07:55:45 -0800 (PST) Received: from [192.168.1.150] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-408afba74bfsm3825187fac.13.2026.01.24.07.55.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Jan 2026 07:55:44 -0800 (PST) Message-ID: <32b884bc-929b-4b27-ae74-5754fa2473de@kernel.dk> Date: Sat, 24 Jan 2026 08:55:43 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] io_uring/rsrc: fix RLIMIT_MEMLOCK bypass by removing cross-buffer accounting From: Jens Axboe To: Pavel Begunkov , Yuhao Jiang Cc: io-uring@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20260119071039.2113739-1-danisjiang@gmail.com> <2919f3c5-2510-4e97-ab7f-c9eef1c76a69@kernel.dk> <8c6a9114-82e9-416e-804b-ffaa7a679ab7@kernel.dk> <2be71481-ac35-4ff2-b6a9-a7568f81f728@gmail.com> <2fcf583a-f521-4e8d-9a89-0985681ca85b@kernel.dk> <3b7e6088-7d92-4d5c-96c7-f8c0e2cc7745@kernel.dk> <596bc7ac-3d24-43a7-9e7e-e59189525ebc@gmail.com> <654fe339-5a2b-4c38-9d2d-28cfc306b307@kernel.dk> <9317bad6-aa89-4e93-b7d2-9e28f5d17cc8@gmail.com> <74f2ec89-ca40-44a0-8df7-de404063a1a3@kernel.dk> Content-Language: en-US In-Reply-To: <74f2ec89-ca40-44a0-8df7-de404063a1a3@kernel.dk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/24/26 8:14 AM, Jens Axboe wrote: >>> ________________________________________________________ >>> Executed in 2.81 secs fish external >>> usr time 0.71 secs 497.00 micros 0.71 secs >>> sys time 19.57 secs 183.00 micros 19.57 secs >>> >>> which isn't insane. Obviously also needs conditional rescheduling in the >>> page loops, as those can take a loooong time for large amounts of >>> memory. >> >> 2.8 sec sounds like a lot as well, makes me wonder which part of >> that is mm, but it mm should scale fine-ish. Surely there will be >> contention on page refcounts but at least the table walk is >> lockless in the best case scenario and otherwise seems to be read >> protected by an rw lock. > > Well a lot of that is also just faulting in the memory on clear, test > case should probably be modified to do its own timing. And iterating > page arrays is a huge part of it too. There's no real contention in that > 2.8 seconds. I checked and the faulting part is 2.0s of that runtime. On a re-run: axboe@r7625 ~> time ./ppage 32 32 register 32 GB, num threads 32 clear msec 2011 ________________________________________________________ Executed in 3.13 secs fish external usr time 0.78 secs 193.00 micros 0.78 secs sys time 27.46 secs 271.00 micros 27.46 secs Or just a single thread: axboe@r7625 ~> time ./ppage 32 1 register 32 GB, num threads 1 clear msec 2081 ________________________________________________________ Executed in 2.29 secs fish external usr time 0.58 secs 750.00 micros 0.58 secs sys time 1.71 secs 0.00 micros 1.71 secs axboe@r7625 ~ [1]> time ./ppage 64 1 register 64 GB, num threads 1 clear msec 5380 ________________________________________________________ Executed in 6.24 secs fish external usr time 1.42 secs 328.00 micros 1.42 secs sys time 4.82 secs 375.00 micros 4.82 secs -- Jens Axboe