From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C3EC4C52D7D for ; Thu, 15 Aug 2024 10:32:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=4cDceMZn7uqMXuiPZnGSyc3mX6R2AhdEkcl6gHQ48aM=; b=rdL9vQyl12N0vm420hZwRVWIVO esU2K9sCvyduoNfwSEG0nTEu5HIGHguoMRNbTKD1N/oE9Nxy+y4bgG8YAg9sRERiCt2H2sP77u1Gs KJ54sAAMU9rjKQ3oY1hLSSVnVA6G0iL0+JzLx/v7PZVwq4LvFHItRFsUq/iGsrDvveMfIsZp7DiAH uNjnIgIXmnUmb9Xb8utR4Sdno0DqAdhAE87LdcDGdFH9gZ6MizdSrafUwmmf+3YE/5d9sEfF+0cwj YlqZbeuTqf88Y7AHk86nse16qK0U5Q+sgM+LK3JhiJjcT81vLpLdf1LHYn3eE5uoFIe6mJXu5hG9z bcfkN71A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1seXmZ-00000009ckI-2lmA; Thu, 15 Aug 2024 10:32:39 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1seXlr-00000009cW2-0bua for linux-arm-kernel@lists.infradead.org; Thu, 15 Aug 2024 10:31:56 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 269F761D51; Thu, 15 Aug 2024 10:31:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7EDC5C32786; Thu, 15 Aug 2024 10:31:52 +0000 (UTC) Date: Thu, 15 Aug 2024 11:31:50 +0100 From: Catalin Marinas To: Yang Shi Cc: muchun.song@linux.dev, will@kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] hugetlbfs: add MTE support Message-ID: References: <20240625233717.2769975-1-yang@os.amperecomputing.com> <7a4a60af-e471-484b-a4a3-ed31daaca30b@os.amperecomputing.com> <546bf8d4-3680-4af3-8d4d-af2d7c192d04@os.amperecomputing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240815_033155_269786_7027989B X-CRM114-Status: GOOD ( 23.03 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Sorry for the delay (holidays etc.) On Tue, Jul 09, 2024 at 10:42:58AM -0700, Yang Shi wrote: > On 7/4/24 6:44 AM, Catalin Marinas wrote: > > It might be better to convert those page flag checks to only happen on > > the head page. My stashed changes from over a year ago (before we had > > more folio conversions) below. However, as I mentioned, I got stuck on > > folio_copy() which also does a cond_resched() between copy_highpage(). > > We can have the page flags set for head only for hugetlb page. For > copy_highpage(), we should be able to do something like the below: > > if  page_is_head && page_is_hugetlb && page_has_mte_tagged >     set page_mte_tagged flags >     copy tags for all sub pages > else // <-- tail page or non-hugetlb page >     current copy_highpage implementation Ah, so you want in the first copy_highpage() for the head page to populate the tags for the tail pages. I guess this would work. > The hugetlb folio can't go away under us since migration path should pin it > so the status of folio is stable. The preemption caused by cond_resched() > should be fine too due to the pin and the page table entry keeps being > migration entry until migration is done, so every one should just see > migration entry and wait for migration is done. Yeah, I don't see those pages going away, otherwise folio_copy() would corrupt data. > The other concerned user of copy_highpage() is uprobe, but it also pins the > page then doing copy and it is called with holding write mmap_lock. > > IIUC, it should work if I don't miss something. This also should have no > impact on HVO. The overhead for other users of copy_highpage() should be > also acceptable. I also think so. We also have the copy_user_highpage() on arm64 that calls copy_highpage() but I think that's also safe. -- Catalin