From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) (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 895AC2F0673 for ; Mon, 29 Jun 2026 19:00:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782759637; cv=none; b=hMlSsrEkhfO/uOtpzVWGuAznxr60IeYOKLphdkWUrJXrhw/uD/bzFybabeeIFi2ZT7ngTnLoTwn8WHOVRxqd0qCmbT7cHR8rplJc5nOfEVyLT7F+AqJMJGQhMkwf+BnVQ13N0RjeDz7WN3D6IKUpKuewEgECKXJnS/h7SqVsygM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782759637; c=relaxed/simple; bh=l8r6yFmmIHtjqnuSEWpRkgzeUDcXmxTyQcjTe3qGURU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TDAlVdHhf2KAGLXPupMAZ0RNuwFEQuBh88A5KQlKUOqTa/al8zAPecpQ45BrhRDH4xa6S5L5SEeFsEZVWvCUlMHeUMcsk5OEXzNkyoRH7NQHVPyFv2JqozSfZtzW7IwS9XeN65b4n78mI7ddrql8eg2ONH1czN737iU9Hi7/yuY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=YW9Kg9NQ; arc=none smtp.client-ip=209.85.222.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="YW9Kg9NQ" Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-922ff615c14so482729085a.3 for ; Mon, 29 Jun 2026 12:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1782759635; x=1783364435; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=V6Ws0acvrk5n2daUvvKItqmwd8qsKqJ9fJgCacpsFrQ=; b=YW9Kg9NQil67ZeeQmCdJ/dbJ2mTwQ5sHB8kWzbE3hsbLElkwt0njT8bsRAIoZv09le MZqlBdQU+K3NFoOMCFpgQV9ToBDzlOvTILyvWC9J/sF4iG2Ad7TflS1XZpE9pCGAOdE1 6ZFKEmZ8M7Bnv5IDb7OvTWLZVHzbzgGPC2stE8r8ztbbISBvAimi450Es7xM/QUvhrxV F9YoGAy+zLN+2Zh32z5B14cefAYj1E4J8prZHj9/1aWbGevF/n8oN3XxGcoLgfqTzN+s GXWV7A19uKhkxtip7Fhq1Q6jpRBtjQWAggiImqXK5phxtZg9rRG1/TQ3FQtarBEM7U1E XdCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782759635; x=1783364435; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V6Ws0acvrk5n2daUvvKItqmwd8qsKqJ9fJgCacpsFrQ=; b=OxlivPhUga1MtSMY4214wjsezO8i1sn1ZUtka31+QfI9t5+ZRBiMnafEyMx988nTr0 uSwDWCsw8gx0/he7G7xpqr7PDDGWi+6gG+sazKU9FQba6prGlS27PCk+Bohbd6IPak/f cO2RJfEhapZCPwTtjLzB5bS+unMzMFtVVoLXAsAsce87PQRh4P6wlykOsQYyukON4Sin NktewqAMShiH8583qQKUy7/gqL5rPwPllG3uxGehRQ38sK95wRg4Ng/1SbBNfv7hCH/M zTCo+4SVRwpoKXkxE6GHYoSXIrBFJaUG1r86MXGzVlrrUCbStrdj14ZTZdOugFIOJp3w LX+A== X-Forwarded-Encrypted: i=1; AFNElJ9IV2nhSuzJxtDwI6PBtA6fjNOBrRa782xXudLX2H9MdZA2Tqs+A6n8BDb4tFQMuwcztwd4cHZFTvgxmjg=@vger.kernel.org X-Gm-Message-State: AOJu0YwhPEWteCDD7zDPZ97EfF37DXJd8RkqhtzPCCJszl/HbsqhmRw7 QWrK5STY9Y8p8Y0bVGTzXJl9xLrQXX40O4aSV35Xvd6iXk8KjaJzlxJuoR1efCC+hks= X-Gm-Gg: AfdE7cnxHoWj8bc1z7PfKM/XmlD9BJ2eiT7TEXzy4N3GufBr7IpKveittne+cYEyKoV bEr4sPFXpbSLb8m7BnKNl4cFg7NkDpj/zMI5qr56D05FLii+ytQNtqLeicr3gIVksTzoKTbiKqS SsTdfZqxBnhjX/5NAtqta6J+MsLs+L9sFRRVY6YzYxfd9QqlFK8O0QJomz2fYC9lzvEThbnR0ao zgxjShrOeTvdnjy+46FVeWrhIa8sqqlOx4z1sMDcHsLYXFW1whMGQ5mEiu4NF1GuvANvuvOqKR6 QAnWpGjzCFuU1kDQ/oEStnYDyqeuG0jEfDy/2WQXD3vKqmBirPZNkRreJtysxHKsh7po0tAMyX4 4qxwPKal+VfivbUbpnrVKlRuTYfImQYAs8DTlc/CWAQ8sU8WoJD53y/pXlUhOwQUhRdKMhttvF0 fyn8bPIeYxNl853+yw+kafS5IUAu9RzaanCLQ6Kg9wF0OQ21o0tbNXJD6n6TcS19GE01Qa X-Received: by 2002:a05:620a:170f:b0:923:5e7:1664 with SMTP id af79cd13be357-92e6267b097mr132511085a.45.1782759635345; Mon, 29 Jun 2026 12:00:35 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-173-79-60-52.washdc.fios.verizon.net. [173.79.60.52]) by smtp.gmail.com with ESMTPSA id af79cd13be357-92e6233a5acsm49235185a.35.2026.06.29.12.00.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2026 12:00:34 -0700 (PDT) Date: Mon, 29 Jun 2026 15:00:29 -0400 From: Gregory Price To: "David Hildenbrand (Arm)" Cc: Qi Zheng , akpm@linux-foundation.org, ljs@kernel.org, ziy@nvidia.com, baolin.wang@linux.alibaba.com, liam@infradead.org, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, muchun.song@linux.dev, osalvador@suse.de, chrisl@kernel.org, kasong@tencent.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, baoquan.he@linux.dev, youngjun.park@lge.com, peterx@redhat.com, usama.arif@linux.dev, willy@infradead.org, vbabka@kernel.org, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qi Zheng Subject: Re: [RFC PATCH 0/8] Introducte Reserved THP Message-ID: References: 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: On Mon, Jun 29, 2026 at 02:20:28PM +0200, David Hildenbrand (Arm) wrote: > On 6/27/26 09:21, Qi Zheng wrote: > > From: Qi Zheng > > > > Therefore, we are wondering if we can introduce "reserved THP", which is THP > > that can be reserved. It can be consumed through methods like madvise(), while > > normal memory allocation cannot consume it. > > madvise(). Gah. No :) > Without going into the nitty-gritty of the set here - Reserved : I care about whether this succeeeds. - Transparent: I don't care. These things are mutually exclusive, so "Reserved THP" is confusing. Maybe this makes more sense as mmap() MAP_ flags: - pre-allocates at the desired size - fails entirely if it fails Since the intent is to *reserve* it anyway, it makes sense that this would be a pre-populate directive regardless, so no lazy-faulting. Then userland can ask for what it wants and if the kernel can't produce it - allocation failed. The underlying system can otherwise use whatever tricks it wants (cma, reserved pages, etc) to get there from here, and all the swap semantics otherwise live in normal interactions (mlock, madvise, etc). Rik's work [0] is trying to move the allocator toward more reliable hugepage allocation with the intent of making THPs more reliable in general. Maybe these things meet in the middle. ~Gregory [0] https://lore.kernel.org/all/20260520150018.2491267-1-riel@surriel.com/