From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (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 23642392C2E for ; Tue, 1 Sep 2026 14:24:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788272655; cv=none; b=FSugxzKHkWGM3UXtB7YIF7gvfI0jVrjEWLavYfVLUaGmi73c5e0BE69dtAdSAAOwxP8PuWc7QKQdOgKNbgAmZb0Zd9JKoNGnnhtIIPx5JcMd2hV3UJbzfOL0Nic6FGqo1NNwpMNVHWD5hO1G+xuXPxvyGC5dpa1+WM8ZEDn7BtE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788272655; c=relaxed/simple; bh=nVSgQIu7Lyxs6Z206eMtmsYLxDTp/HpmK2SloWeSO8k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WsPsmIfeEyvqhRkxMlW1I+X4Si7MVKng24m5ky4/TLD4ntjD+RLi/tGIM4JB2YwW/ZEp6rJYIVDNZKonfvleLXpGQQyaq+TE/rYfaWi0iSGrJiOENaf5lT7XlWlhDHazCvhUwOwQ2FBnB/hWqnvb/SmY8rXy844rq3vSmcCyhxk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=oz5WIptN; arc=none smtp.client-ip=209.85.222.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="oz5WIptN" Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-92e55b62640so311536685a.0 for ; Tue, 01 Sep 2026 07:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1788272651; x=1788877451; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=AMNw5MzyW2DJkQCetuS4jMUrMgDtCzVkmjImJH3QcQw=; b=oz5WIptNee8XscHGuyC73cFevp79vDp/jDAMb+2q+59SuGSoi67v5MkNHcxr65xj7o 0zOFE4FAsCPnTdIAM3vjpfiOMPpCW1KUYnODQk5FhGFD2C5m4t8oD/T8RzTa0vI4KLY6 VYiu+gIr5k8HK7PAc7MhxiIv2pu/5TcOPTikAr2vSIK4zY93Skb23FNU08GQg+7bPLe0 2P98vbitp916TNQAzxQGjZca6Y99nmOJ+NtUBeP0SeQ5bEWWO4fd9XBhtidPO5tRD5N0 +67eMFyk6Zbi30fyMJekEa3YR9DffpJswP1P8XXMR7RmGdLsXOt8maaV/bmh2r9mChqr NB5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788272651; x=1788877451; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=AMNw5MzyW2DJkQCetuS4jMUrMgDtCzVkmjImJH3QcQw=; b=WkphRBryXsTT9AyehbX/cXLcYzyjAqebd6/FqZZhhZ0pW9afHefG2VcKWPEj19hSWG RlLokcL94gyxNolvxHzuV+6JKGaJUhE1XEbNP67KE9x7ztjFtJWMNPi1a01+ZUFQjU8U 6zn71QhqIB6r3HCfyv/H2Yp3ZJViGzF6FATNSDaIE7nkdzV8ymuiYOUkclTkL0e4o5xX Yivfa++ggoR2b0lfuKJUoJsrnJfn07ce6TOK6I7T7eZ64Ag+8+vHXQ8hqhBHJGd7e9q2 gdyjy4KzplbnbFrQQEtya/7wniWMMB3fCG8N1eRq/gasntcWQX+hEcaJt5Z6bZZIkLXR SMZQ== X-Forwarded-Encrypted: i=1; AHgh+Rot4j0vuPno9bJcMD0+nSflX5FgdqtEF8WfGbMItSCs1NKMsxgnRtNB95JGMnmKGTUR7kgh/S1SeLzJ@vger.kernel.org X-Gm-Message-State: AFuF++kHwRm4VOUhltdJyYRVyanF7CZxzC9uaFEK0dXSDj+7H6HgT1D7 MbgjpEUEeWlIBNygrh34Ip6YL29lFOnxWBe5tbDnWKzugFzCL9R9EjfVdT8V1z6b3mI= X-Gm-Gg: AR+sD10gipb9VtowaZterq7H+nac1X+cVCiFB+ISioVgZ5SyqDlspv009jGPKOD0pbQ VdEyI373BQKJnp9BC7POfaMwrV08hu0LsDTtvLAcrjhmgALba7awKFT8AaAkQdJN+gDCwyfZY6j DTgiKg5vAG5iy3crdaQCt5EhwujvcJP3pFFN3S/ygXfGnQFtHedDn+yz1MUF+dLGlbRWB1BBM6H BEs5INiTwunzmxzs8/dW5X0b0FC1w4o0T5GCGTTHOI7yz2c+m4wB3r5E2XXGODBXg4vvSSsQ6mH xV8M4Wph2xshVHnCzWkDSaree5BBAOuZxteGN46t8pz6npmc9nLA2vwSZdi7D/DM9K0Qb7Ww1Pp 5bHKesl+0UjMWRlFOSdLFbjZv6Q1nM1kwUMPB36NQjeP9UC7q5YSXBQNVeXzt94HuLHA17v9Sn1 FhPHgRoLOI1ZMe1tfAcBjmPxkHoYh+qCg+agsA5lG3fJdh/ncfsFGmBCnuvXiRnCyMUjA60UaPI QCkJXBR45s9wo+l+2PkdmKnBUItCynNqhrCr3nvzFN8yg== X-Received: by 2002:a05:620a:29d4:b0:934:ab73:ac53 with SMTP id af79cd13be357-939134fe550mr3924451085a.0.1788272649971; Tue, 01 Sep 2026 07:24:09 -0700 (PDT) Received: from ziepe.ca (hlfxns010zw-159-2-239-150.pppoe-dynamic.high-speed.ns.bellaliant.net. [159.2.239.150]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93917012b65sm1040535485a.2.2026.09.01.07.24.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Sep 2026 07:24:09 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1x1PPE-0000000BgeE-10ID; Tue, 01 Sep 2026 11:24:08 -0300 Date: Tue, 1 Sep 2026 11:24:08 -0300 From: Jason Gunthorpe To: "Lorenzo Stoakes (ARM)" Cc: Kiryl Shutsemau , Andrew Morton , David Hildenbrand , Zi Yan , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Guo Ren , Brian Cain , Geert Uytterhoeven , Dinh Nguyen , Simon Schuster , Jonas Bonn , Stefan Kristiansson , Stafford Horne , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Russell King , Vineet Gupta , Michal Simek , Chris Zankel , Max Filippov , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , "David S. Miller" , Andreas Larsson , Richard Henderson , Matt Turner , Magnus Lindholm , Catalin Marinas , Mark Rutland , Huacai Chen , WANG Xuerui , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Madhavan Srinivasan , Michael Ellerman , "Christophe Leroy (CS GROUP)" , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Arnd Bergmann , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , John Hubbard , Peter Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-openrisc@vger.kernel.org, linux-sh@vger.kernel.org, linux-riscv@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-snps-arc@lists.infradead.org, linux-arch@vger.kernel.org, sparclinux@vger.kernel.org, linux-alpha@vger.kernel.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-um@lists.infradead.org, Hugh Dickins , Qi Zheng Subject: Re: [PATCH 01/12] mm/huge_memory: zap deposited page tables after an RCU grace period Message-ID: <20260901142408.GA56830@ziepe.ca> References: <20260901-rcu-pagetable-freeing-v1-0-5456a81c8212@kernel.org> <20260901-rcu-pagetable-freeing-v1-1-5456a81c8212@kernel.org> Precedence: bulk X-Mailing-List: linux-s390@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 Tue, Sep 01, 2026 at 03:12:45PM +0100, Lorenzo Stoakes (ARM) wrote: > It won't be costly at the time of the calls obviously as its deferred. Maybe > increase some time spent in softirq but again is 512x that big of a deal? > > I'm not sure how you'd both defer the free and somehow utilise mmu_gather here > either really, certainly not without it becoming extremely messy. The less costly version is to thread the page to be freed onto the mmu_gather through a linked list in the struct page memory. This is super cheap since it is just a singly linked list operation. Then when the mmu_gather is flushed it does a single call_rcu using the rcu head of the struct page of the head of the list. The callback clears the entire linked list of pages. Since you have to tlb flush anyhow, it makes sense to always use the mmu_gather. For example the design I ended up with for iommupt accumulates all the invalidations and all the free-able memory into a gather then invalidates and frees. This allows maximizing the tlbi efficiency too. You can't do call_srcu until you flush the tlb and if you call once per table then you are also tlb flushing once per table too. So if the kernel really does want to clear out 512 leaf tables the optimal implementation is one range tlbi for 512 entries followed by one call_rcu to free the memory. Hence the gather.. Jason