From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (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 51F8B1B4F1F for ; Wed, 1 Jul 2026 16:22:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782922950; cv=none; b=fKis0GgVnnopElT6pImpFGeN53OchYqsAkCchvCN48P2XyVazAobnAtciDFDi8SBu+d6y1CMl5PWCI2BjW5knF8r4i+QVrmnIxM5zIkOiEcGYVkMBGrWKxO1bUwqZpTIRj53Znc3U/nJ5NOtGWP+dtWwrGcVl2bN7oEzVIrNhu4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782922950; c=relaxed/simple; bh=eA1t4797ErJjcQIeL2hEqAQhsnbzlUOorfwsFEkryAA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=V2etiYihq4i0qnUvHrg4J1jiW8iwT9WaF0USJR5m0IfR8NuoITgwrB78KapfZAbF7PM2JO6VYqfCdL5YGMIRPZOKamwrcwRMoFpEYfgLDZsZHHimFdLS28/I9lTB/yRvhjTA167vyFuu0wi9FazPNebbh7lMOXneAKBYJZZ0bkA= 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=Sruokczg; arc=none smtp.client-ip=209.85.219.46 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="Sruokczg" Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-8eaa7b5e31eso15143436d6.0 for ; Wed, 01 Jul 2026 09:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1782922948; x=1783527748; 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=sHnHhL4KJ9c8uWbCwjG8ADlyevSzQk8rSYgChOMGpvc=; b=SruokczgCAd1XBjrirY435+OuEVKXptt3GchoMIcESkDTWXVcrnUwYWsWR46sWS/VI 6tsawivX3GJUR9wJYeJr20u+i/WITfO9NJO15X/ljXbTXl1j2GIaME/iUFgNC/SzyDwn oZtxHJH13Sm2aezwdSalmamRdZZEOLXPnFCuIX9qO/Y0oidVF4naDn/lyliJOJwviSMw 7N7MRXyIrXvjuDJcHY9IOaArx4NkfGk+Pv7fjExn1jxlvH4C29L7tsFjCmfLgSVc+6LM GqNJ8VFg5Ta6dJ3MjxDCXv66bNwPUZQAloDYNes2qCqVxJrEugB70OnMOgOuCx+Mg7fk tVlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782922948; x=1783527748; 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=sHnHhL4KJ9c8uWbCwjG8ADlyevSzQk8rSYgChOMGpvc=; b=Ir/CwLmafkEPq/+3JPgRoj/qei6BQfA39q1QvaO4nnjC++0wPV7JAM2PxgUPNWanHp /DOgDkX4hUazmTaX854iQauwcogzUjW6/mjmhD4gcKZQKogwonWaDlNXuqXWggHZFiad 9PeB8v+Ir75x6UoeT/XoBckfBWjEwm8kirxENXscVujNyWFVwnOt+a0s9Pi5k54tGAnP h4W9pLx3LA/pzQUtR2ZxqaqAQtWUp11weoypnxsee989Y6EqIdHooo2PVwgJqubefU85 dtu0MDaHjOLrgXrVsaebtUoyOJxlG4Op7Qs7RM43TxHkwv30xO4FVB2/XACFl8QP+sKM yNXQ== X-Forwarded-Encrypted: i=1; AHgh+Rr1dv1ywHzrUA0qa65nYhe1rsGS5HFpNRM6+iEIZvm5jK7lKkv2a9HZe2mPD3Bra/QmOCk9GAX8XgIvGRs=@vger.kernel.org X-Gm-Message-State: AOJu0YzhnrORO2RKwXr5Q47wKe3RKwPjgPLoeeveD7GbB4j397zAE5qO 8IZGW1LqvpCx2u9ZjRu5gnMW1zEKjUG1xWgVzNSxkI0Oa7IhWZl6Brat35YtRoMDW2o= X-Gm-Gg: AfdE7cmyw+a94pnTE41jQZSFuluPFj0uYXIH0575KOOY9Z254glUk0GonOqnkoqUhqx npTdG1dZ8G0k1s7pXOJMvMl5NGY2z5MXIXpN7vKlNsb4297OFEWeyVWfDlCRvTpNbohvSFB4Uai syfAt9GF+Y357ab5x0e4zxlN2AnI5IN7WjVT1210bmUACjbtpNXiNyXDKZnYlUg0mAINVVrstU/ 2FSKaRuJGW/azx7cilOTH/cnw2e6fY9ttf/slo1ZGzUJtYwCYT5Qko2P6TXV+uqo5aQkypItleI w67/m1YlF+y9TcN6RIA8rwSKFWXpjT2s8mNdc/z4iyidFPGd0uWT/t96d54K9fSYnwbs4uuxxMe r2+aX2mhqHdNyqe/Zh13uGpp2xScM07I7QIEotvyLvopWmyyx3UuczPTQk+ncOilVqEUVJJlxGI UJB/Bm/xbqslMeHITNDFezEiWSweQInPVwhTx417eWp99MFDZ1BsSfy1pkJzPzrdT0QlpE X-Received: by 2002:a05:6214:5902:b0:8ee:d9b8:8538 with SMTP id 6a1803df08f44-8f3bcdfc8e5mr36360526d6.9.1782922948120; Wed, 01 Jul 2026 09:22:28 -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 6a1803df08f44-8f471813f56sm995226d6.30.2026.07.01.09.22.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jul 2026 09:22:27 -0700 (PDT) Date: Wed, 1 Jul 2026 12:22:23 -0400 From: Gregory Price To: Johannes Weiner Cc: "Huang, Ying" , Andrew Morton , David Hildenbrand , Zi Yan , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Alistair Popple , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Neha Gholkar Subject: Re: [PATCH] mm: mempolicy: fix automatic numa balancing for shmem Message-ID: References: <20260629163337.1264881-1-hannes@cmpxchg.org> <87h5mkz33h.fsf@DESKTOP-5N7EMDA> <877bnfynsr.fsf@DESKTOP-5N7EMDA> 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 Wed, Jul 01, 2026 at 11:49:16AM -0400, Johannes Weiner wrote: > On Wed, Jul 01, 2026 at 11:33:38AM -0400, Gregory Price wrote: > > > > I considered proposing MPOL_F_MOVABLE_ONLY to mean (roughly) "userland > > memory only" - and then slowly trying to migrate numactl to make this > > the default. > > Hm. Kernel allocations that are totally incidental like the stackdepot > example above should not follow task policy. But there are kernel > allocations (kernel stack, inodes, pipes) that are directly allocated > on behalf of a process, and so probably SHOULD follow task policy. > > That's an annotation problem that I think we have solved already, > because cgroups need the same distinction for what allocations to > charge to the current task's cgroup context. > > We could rename __GFP_ACCOUNT / SLAB_ACCOUNT to __GFP_TASKPOLICY / > SLAB_TASKPOLICY or something, and have mempolicy follow it too. > > There is still the whole "changing 20 year old behavior" aspect, but I > think the polarity works in our favor: big important allocations have > already been following the policy correctly. The behavior changes > primarily for smaller, random allocations. This seems like it would be a pretty trivial change. something like: static nodemask_t *policy_nodemask(gfp_t gfp, struct mempolicy *pol, pgoff_t ilx, int *nid) { nodemask_t *nodemask = NULL; if (!(gfp & __GFP_TASKPOLICY)) /* don't do the task policy, numa_node_id()? */ ... snip ... }