From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-178.mta0.migadu.com (out-178.mta0.migadu.com [91.218.175.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 60A9E34D90D for ; Wed, 17 Jun 2026 15:56:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781711800; cv=none; b=Lkxwc8meC/oVMSjwRld/0+dKvDA7/dqtv+3tzcgvQN3mfSq7Z43VRHWDm++dQ2XIuUYMKXDVRiUfW44mZVbGGyOjkamZDE2yg4QchZ3HDClFEQfkzRq1F1nf/aEnq4DGVGIN2tEqY3m7dMIUsMROddeUVHyqiHRA54HPkrwKcHQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781711800; c=relaxed/simple; bh=2XeOL1rHE16VU0QcSmgVUYegX+NYgJCboVSUqU+8UmQ=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=jb08Ql8ozgaQGy6U7ou2ZFA1BA28n7BGdFxKhN5AI9AUVXT2FLxleJ0a1kL6ryAh6KyibwKDRVvcWQnhlzPES92B5I/RERnb5OBfINslhNX3RmyHth9UR14rq5JbLBGhCyLeX44ZUsPuslE3oPX8A4RO19juKlop+Wequk3HWnI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=T1J/WI1K; arc=none smtp.client-ip=91.218.175.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="T1J/WI1K" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781711786; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MAW/jHNB+s73bmq2RK9pw8vdXIwRnuLexugbKU7MQww=; b=T1J/WI1Kel1qpBrOpKglPcwis+2PhWxb5gyj0zwbqYuS/7xBSLBcS8KAxN1wGf+rFBSIbU 6ZXYlnf+6irMQjApOiGijrQ6tgNGaLSYeKt27oRQ+UX24d1clXwr3q8vTORfDZ7wT0msJp YdQC8SYqQrXLKEyeHZKZWKPfs7IRYtk= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 17 Jun 2026 15:56:21 +0000 Message-Id: Cc: , , , , "Sumit Garg" , , , "Will Deacon" , , "Kalyazin, Nikita" , , "Itazuri, Takahiro" , "Andy Lutomirski" , "David Kaplan" , "Thomas Gleixner" , "Yosry Ahmed" Subject: Re: [PATCH v2 20/22] mm/page_alloc: implement __GFP_UNMAPPED|__GFP_ZERO allocations X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Brendan Jackman" To: "Gupta, Pankaj" , "Brendan Jackman" , "Borislav Petkov" , "Dave Hansen" , "Peter Zijlstra" , "Andrew Morton" , "David Hildenbrand" , "Vlastimil Babka" , "Wei Xu" , "Johannes Weiner" , "Zi Yan" , "Lorenzo Stoakes" References: <20260320-page_alloc-unmapped-v2-0-28bf1bd54f41@google.com> <20260320-page_alloc-unmapped-v2-20-28bf1bd54f41@google.com> In-Reply-To: X-Migadu-Flow: FLOW_OUT Hi Pankaj, Thanks for taking a look! On Wed Jun 17, 2026 at 11:32 AM UTC, Pankaj Gupta wrote: ... >> +static inline void clear_page_mermap(struct page *page, unsigned int nu= mpages) >> +{ >> + void *mermap; >> + >> + BUILD_BUG_ON(IS_ENABLED(CONFIG_HIGHMEM)); >> + > > I was thinking =E2=80=94 would the fast path read better if we moved=20 > migrate_disable()/migrate_enable() up a level, into clear_page_mermap()= =20 > itself? i.e > > migrate_disable() -> here > >> + /* Fast path: single mapping (may fail under preemption). */ >> + mermap =3D mermap_get(page, numpages << PAGE_SHIFT, PAGE_KERNEL_NOGLOB= AL); >> + if (mermap) { >> + void *buf =3D kasan_reset_tag(mermap_addr(mermap)); >> + >> + for (int i =3D 0; i < numpages; i++) >> + clear_page(buf + (i << PAGE_SHIFT)); >> + mermap_put(mermap); > > migrate_enable() -> here > > Right now we split the migrate_disable/enable() a layer below across=20 > mermap_get() and mermap_put(). > > Would it make sense to embed that in the clear_page_mermap() API itself= =20 > =E2=80=94 mirroring how we already disable IRQs at this level for the=20 > mermap_get_reserved()? > Hm, I guess the symmetry would make sense. The reason it's this way is because the mermap_{get,put}() API mirrors kmap_[un]local_page() etc which do the migrate_disable() internally while there is no precedence (AFAIK) for an API that automatically {dis,en}ables IRQs. That might also be a side-effect of the fact that local_irq_save() requires a local variable while migrate_disble() stores its state globally. Similarly, there is no equivalent of lockdep_assert_preemption_disabled(). > Thanks, > > Pankaj > >> + return; >> + } >> + >> + /* Slow path, map each page individually (always succeeds). */ >> + for (int i =3D 0; i < numpages; i++) { >> + unsigned long flags; >> + >> + local_irq_save(flags); >> + mermap =3D mermap_get_reserved(page + i, PAGE_KERNEL_NOGLOBAL); >> + clear_page(kasan_reset_tag(mermap_addr(mermap))); >> + mermap_put(mermap); >> + local_irq_restore(flags); BTW, writing the above just made me realise: we don't need to disable IRQs here, only preemption. In a WIP version I did have mermap_get_reserved() requiring irqsave, so that you could theoretically use it from an IRQ. But actually I don't think that makes any sense since it depends on state in current->mm.