From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) (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 AED7331ED80 for ; Mon, 8 Jun 2026 15:57:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780934227; cv=none; b=C6QHodSAPbOFjaQO2uNCyHht7TxvIclmhm+Q+HiwglplLuhyJ+Bgwsry7MI4+xyehnLRhuaYTy8Y7q0GZ+S/xw4peyRas9xRdQHztoESzB74otW0Am5aXoXdl53kbnH+vn4cwfnVNu9OlGmEyRBDFROdra8v8w2ngOGDqcsbSkg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780934227; c=relaxed/simple; bh=945iUaWaC+0sbuwhc+JD3qPOzJ9LHnPGhsHw5uznNhY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=TuMvDL6dEO79lCdZveXXuZ8BbMjyE76q6yXKUliOmopLGueKJE+qIEUi250StiVk6PEbfeHeWjAe2yrmFaiMySEIg4SgB4SMUSGzLcp4o2REcMLI23QdPqnSyz01V99wxss8ewHWLhdov4xoBd15tCkq8hkw/X176U8ksAiKn7Y= 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.20251104.gappssmtp.com header.i=@kernel-dk.20251104.gappssmtp.com header.b=cbvf0UxF; arc=none smtp.client-ip=209.85.167.180 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.20251104.gappssmtp.com header.i=@kernel-dk.20251104.gappssmtp.com header.b="cbvf0UxF" Received: by mail-oi1-f180.google.com with SMTP id 5614622812f47-48611862583so2150439b6e.0 for ; Mon, 08 Jun 2026 08:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20251104.gappssmtp.com; s=20251104; t=1780934224; x=1781539024; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=uboJEfGdeULZH+WbPQgJR/aqC2xi1VBsBXohsfanUA0=; b=cbvf0UxFRPMIPk2mzPAS+ey7LH5mjq0ahRuhnbmtm7MMpbg0zwWVoUl1Y+b+RcpPm5 v6f2hzkWU4lacBzM+LYRGwzyThWPtb6mKAfHllD3SqM0e0OwiWRJ+HfC+iG/lMNZi3z5 tPkP0kHtloCwrHYF+7TeHf/9+2/X0+YBvIN/e18uFlXtLTrXuqfwCGtVZmahpCrOw6fB 6BWovpsJSSgU83FUCjoITZLIIsQxc5fxYHN7PSdq22KTuc5WVDJ9lRRO13D6Vo4od0Ft gtyno2h0/D3BPxAS/4Yp2+hEIDDHWcIcOCEIYWPUx0ylJQaFKTmODOz+RadIW6HXXQ6I A+sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780934224; x=1781539024; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to: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=uboJEfGdeULZH+WbPQgJR/aqC2xi1VBsBXohsfanUA0=; b=Yducq1kYl3DIFz4WGFFO6AlEwfPYtwXwHuu70wW3v7vRpjZALXH1iOfbvRYVJgvEaH GtGTCwftZEaVbtSekRROY4N9ZUqzrVD2jJGfaE0Mc/IUWAlYPqYa7HoF0olJfnu9Uk1/ x0zI1OM1DnUYV73OvQqxmxWD0QhawkVjrIFyc3EuWNiY5bXZ9O665TbCaTEPoNk/UHDO HQBmz/rIC7H6Nzj9HQPoBwcLeu6LR0XkbLFr8EQj6Ca2lsYraeGlK682yKKp1Mi6I38P lPZY2ivjd1KS2fFvlFHpyJTZWtPLumwzsvFzJnTw/vL88EB6Uk39eiJR94WpuckBvlne 0HWA== X-Gm-Message-State: AOJu0YyNT1MNWRMKrH2wHYV27/2b+1gR5lJwqL1DRFmczL9CTP5AGyxu rsquVC4NaN/6N1frB8QlEhvvPOHQyggLA7Z/gxmgyoZe7vJm/1KONs6mABVrhAeB6JA= X-Gm-Gg: Acq92OEd9M9BuCfA+eSsfN6KqTlmUbqhG3KDIqmFxoEQ/jGePkch3KOOnnyXt7F6UyA Vq5CimWaufQwxAJ+6ZcZ5WaERuoiITDx727nBVZCDVJwgATJTSQORPC/6JxkKwWpy2TqkMrpqI8 8c4hDZ+qalCl7sMKMyiVkjulZmtWAWxYkCazXrQ+IUjMescYrrSXscrn7sic4zTp6KCZ/5FwAAz N4bO26nn2GdG6bSanBAB47JAYbRp2w7qpqNLx4KDlnq22pB9+0DDAEK8FJPNUmqkdvJ1mdxdyaD ItF+XwhFi0vIL+x8DP4DNFdMLE8cUd6Jl1u3IgXC0+Z0oq2i3dU5t6Bda2isT8B6buBJ09Ci3lv 58gSztw0Irl2u5CrbgnZ9XdAwtBeIVAovMBKQz2uN6LoB8Bj9zMqfkUZuv3jjAZSxh6CQYPwpU+ OMSk8kQFxc2I3nITgC7qbdN2aKHtc/xvYH+sLrjilvqCZidpDgtOUDlomtHSfxxWDR3zxk+g2xR 94wHOSsFnnD6z76rSks X-Received: by 2002:a05:6808:1b25:b0:486:560d:aa9c with SMTP id 5614622812f47-4868dc63516mr8563993b6e.15.1780934224561; Mon, 08 Jun 2026 08:57:04 -0700 (PDT) Received: from [192.168.1.150] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id 5614622812f47-4865b5a53bcsm13980952b6e.3.2026.06.08.08.57.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2026 08:57:04 -0700 (PDT) Message-ID: Date: Mon, 8 Jun 2026 09:57:03 -0600 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: [RFC v1] io_uring/rsrc: add fast path huge page handling in buffer registration To: sw.prabhu6@gmail.com, io-uring@vger.kernel.org Cc: linux-kernel@vger.kernel.org, dave@stgolabs.net, dongjoo.seo1@samsung.com, Swarna Prabhu References: <20260608062937.804758-1-sw.prabhu6@gmail.com> Content-Language: en-US From: Jens Axboe In-Reply-To: <20260608062937.804758-1-sw.prabhu6@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 6/8/26 12:29 AM, sw.prabhu6@gmail.com wrote: > From: Swarna Prabhu > > io_uring sqe buffer registration path returns pinned user pages in 4k > granularity. If the first pinned page is in a hugetlb folio and > pages[nr_pages - 1] is also in the same folio then store a single page > entry and report *npages = 1 while dropping nr_pages - 1 of the pin > references it took earlier. > > io_uring has support to identify and coalesce multi-hugepage-backed > fixed buffers from the function 'io_check_coalesce_buffer()'. However > we need to iterate over the entire page array and this patch bypasses > the additional checks for this case. The fast path reduces the overall > sqe buffer registration time that are backed by huge pages. > > Measured with fio on bare metal backed by 1024 boot-allocated 2MB hugetlb > pages and setting the cpu cores to governor for max performance. > (hugepages=1024,hugepage_size=2M): > fio --ioengine=io_uring --rw=randwrite --bs=1M --size=2G --iodepth=256 > --direct=1 --numjobs=5 --fixedbufs=1 --registerfiles=1 --iomem=mmaphuge > --hugepage-size=2M. > > Avg across 3 runs: > Metric Upstream(7.1-rc1) Patched Delta > Reg time(io_sqe_buffer_register): 3797ns 2970ns -21.8% > Total reg for workload: 14.35ms 11.34ms -21.9% > fio write bandwidth: 1416MiB/s 1416MiB/s No regression This looks pretty reasonable. Curious what inspired this change though? Workloads that register and unregister huge page backed buffers at a rapid pace? The registration path should obviously not be slower than it needs to on purpose, but it should also not be part of the application fast path in general. I'd expect most users to register their IO memory pool upfront and then never really touch it. Can you expand on the background that led to this? > Signed-off-by: Swarna Prabhu This doesn't match your From: in the patch, that would need to be corrected. -- Jens Axboe