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 F24873932D5 for ; Thu, 23 Jul 2026 17:48:33 +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=1784828915; cv=none; b=QZqpc/LFzeDNw/8WCKa/HCflBm4f4XCUUvWhB2cpk7p4t2M6/sQg/aAJKfKuoYWZImnQFkGnZgOuDp/jaK6dsNCXvkkJnZplBcXVOivbpPk3p7CdLsh1gfrm95lg1/9Fv6An2mjtv0BiUwk5xxcwXUJ4mk8e992+Y5OadbZqro0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784828915; c=relaxed/simple; bh=vOfWiDHu8KJHXpLZNL4rujIBCQsIEp/ffLVBXHg7tac=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pPSbgymoBDdWiBEPDSGdVmiqhh4n+6uAn4iai8EX/s+w2Jxsxvgh8Oqb68sVk4nFIBC3eGFCclH1qIfClHnyAyFHp0pegoGRGQJBNEz6T+7rq3kH7t9Qrwu0XuXw+RfOwzNPC3c7Q2dVphmuOqRHaT9wmgnKtWrIqfo9TTg8gH8= 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=b2OV5hok; 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="b2OV5hok" Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-8efcfdb2b43so8034356d6.3 for ; Thu, 23 Jul 2026 10:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1784828913; x=1785433713; 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=G2+4/YWWiPL/NjZ7kD3wcGqD98ci6jBKaqWoskADH3c=; b=b2OV5hoke2MYSUVGR7eJfxpU04wj6HOd+SItWjZfaAG2dAzzbFS85HNdqgmhQXR3F9 Qn+HRwBJORjSFYm6qHCX99MaLHKwcADPb13ecOV+tMUNnB/bAPGTbngm5//z+YC2pL7A B2GDaCZilCefNv9Mr981OcQD1psk3owdpsF3Rjnz69KmBj5EfuZJI70fSD5CPbHImz9a 8GARXEw9CR0PiFjKoWIUQQOLOqtS6VyOYGWBFlD/j2Me2zv/LlIVWhFf02v/ARk86ZBe xZ0PBU2zEEaV+RQeT/fsqXYbz6y1uSye8KIfOPUDypfBT6SLPh8M7gx2rXtA7IkSAZwC Dp2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784828913; x=1785433713; 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=G2+4/YWWiPL/NjZ7kD3wcGqD98ci6jBKaqWoskADH3c=; b=sf3uBUjGP+stKXar/LLwSgBt/iJ2XX1s6Qy64uUs9PATvMHsqvbQ2yJ9nN31FcKsBN LVTjCPblUWp3OxWiwlK0c+HZOe3E7PHtTg5LSDAcIowWRNU33rb1UHIo1E84MVX6s/GB jz0s1xulJr3PuNL55AwpjCYAiO0POFrcuKIGUqrp82n3pF0eL+IYugSW3VDSVWDCvTnW basf0jLHuv1S0V1+yqypUU8IZPBrpWfE5XJ4Se10jbZ7xShLw7qOkBC/4ZqOLQBpi/UM bm6US9i8tSlmcXtrCCdpuVfjTqaIXmXX3ug9snqPVTGtcunO8YC7wX24hlDRpkBmmI9J wK7Q== X-Forwarded-Encrypted: i=1; AHgh+RoI+EC2Ukq4mJYINniWnP7jJ4/ZhH0tjMqLPW+Rn/LI+HggvhGtid0seRSyGeAyAmeY8ac5RrPeTgMOCfQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzfnqHpDUlV0YRLnLH5XSQwEFd+n/tasPpXsdWrc3QjPS+ibty2 sV822MV8xci3Vd5P+rY0hS4yAWH+MZki/Np2mRelY65FC2MHyB/biWO33ZWdVd3VLfs= X-Gm-Gg: AR+sD10a8d6MgMr6QmQOsDJyBzo8dgjVCXnWieNdIwUT70Em82qMOIUI8GlypcS2scV ATPVz3S1UqcRSz7Knwem7HvbLXJSO+aARRw6iYQh7/unOVaiwwkAFfOd2HqSDmuyZZp1Odgord5 XJj4X4QJDPsqWLoUy57B+u85XtIzmTZxLRjQkKMNnFeKIIhkQiz31hIFnlawejiV1GaTrHnIekb Ntscn+9Mwc2ozRhStHzIqIUgn4fgwGo3iz5ln9sJu1kH6D5UHEQbmaQtmmlVwaeepa/Jda22UiQ PsrlkP195klUbqVrh4eZCPhceboEaHHhudEnh5nbUqq87Ba8bnR9vgETyLtbyvAnZdGZwh6uZ/B /9lDF9yPK9Q7fnnZEOPQenyyPqMqeScb9zGfz1sguBU0zicQmiATuToxjQe3Uyad4EYhoDLKgto 2AMEH6IGtJziPmwSfKT+ZCLFj80ModxKFicYKtDvXUdEhrPEXJo6FfeXZoVQ== X-Received: by 2002:a05:6214:3b87:b0:907:75b9:b101 with SMTP id 6a1803df08f44-907ca3506dbmr49693546d6.32.1784828912139; Thu, 23 Jul 2026 10:48:32 -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-907baa09dbcsm50354966d6.34.2026.07.23.10.48.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jul 2026 10:48:31 -0700 (PDT) Date: Thu, 23 Jul 2026 13:48:27 -0400 From: Gregory Price To: Johannes Weiner Cc: Sean Christopherson , Yan Zhao , pbonzini@redhat.com, Andrew Morton , David Hildenbrand , Zi Yan , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Ying Huang , Alistair Popple , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Neha Gholkar , kvm@vger.kernel.org, rick.p.edgecombe@intel.com, vishal.l.verma@intel.com Subject: Re: [PATCH] mm: mempolicy: fix automatic numa balancing for shmem Message-ID: References: <20260629163337.1264881-1-hannes@cmpxchg.org> 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 Thu, Jul 23, 2026 at 01:07:04PM -0400, Johannes Weiner wrote: > On Thu, Jul 23, 2026 at 11:58:27AM -0400, Gregory Price wrote: > > > > I lean towards Johannes' stance here that consistency is better, and if > > KVM has a known-poor interaction with numa balancing, maybe KVM should > > simply set a default policy (when none are present) to avoid this. > > > > That said, this is painful because MPOL_F_MOF / MPOL_F_MORON are already > > a silently inherited policy on boot (added during init). This will be > > confusing for users. > > > > This is not documented anywhere. Maybe this change should come with a > > docs addition that says the default global policy is ACTUALLY: > > > > MPOL_LOCAL + (MPOL_F_MOF | MPOL_F_MORON) > > > > Instead of just MPOL_LOCAL and letting that silent implementation > > detail bite people. > > Hm, where do you see "Instead of just MPOL_LOCAL"? > MPOL_LOCAL is effectively the default, that's what most people expect. > Documentation/filesystems/tmpfs.rst says it defaults to "default" and > points me to set_mempolicy(2). That in turn in general makes little > mention of numa balancing and doesn't mention MPOL_F_MOF/MPOL_F_MORON. > In fact these are documented as internal flags. > They're "internal" and generated by passing MPOL_F_NUMA_BALANCING... which is basically shorthand for "use (F_MOF | F_MORON)". There is no other user of MPOL_F_NUMA_BALANCING. The internal/external state of uapi/linux/mempolicy.h is frustrating to say the last. > The numa_balancing entry in > Documentation/admin-guide/sysctl/kernel.rst however DOES say plainly > that enabling this feature will sample and migrate mapped process > memory to where it's used, and that this has a performance penalty. > > It seems there is a general lack of documented interactions between > user-requested policies and the system-wide numa-balancing behavior. Agreed, that's basically what i'm pointing out. This is what most think they're getting: static struct mempolicy default_policy = { .refcnt = ATOMIC_INIT(1), /* never free it */ .mode = MPOL_LOCAL, }; This is what they're actually getting: struct mempolicy *get_task_policy(struct task_struct *p) { ... pol = &preferred_node_policy[node]; /* preferred_node_policy is not initialised early in boot */ if (pol->mode) return pol; } void __init numa_policy_init(void) { ... for_each_node(nid) { preferred_node_policy[nid] = (struct mempolicy) { .refcnt = ATOMIC_INIT(1), .mode = MPOL_PREFERRED, .flags = MPOL_F_MOF | MPOL_F_MORON, .nodes = nodemask_of_node(nid), }; } } So the default global mempolicy is effectively: (MPOL_PREFERRED | (MPOL_F_MOF | MPOL_F_MORON) which is just MPOL_F_NUMA_BALANCING without MPOL_F_NUMA_BALANCING. The user can't actually see that - because the MOF/MORON flags get stripped out when it's queried (because they're internal only). Maybe we should just set MPOL_F_NUMA_BALANCING in the default/preferred policies and document that the global preferred policy default-enables MPOL_F_NUMA_BALANCING - and that if a user (KVM) doesn't want to be affected by numa balancing it needs to set a policy to disable it. ~Gregory