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 AB28F39B49E for ; Mon, 16 Mar 2026 14:07:28 +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=1773670050; cv=none; b=LVG3SwKbawi7mGdHn+EtydfrPO1BdeT5/wwDcUsVrj/Dr5stQtzY0WYDkSeCnk59N47MFdc+zxMRDuPNy6HD6V1JuYXnDdogV8RMUBmBEMQOXcczwRlNoJ/LoRVDrPXugl7cTbTcM8+c3DJ0Onk5sYrY8bcSVieTBtRyt9CWMP0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773670050; c=relaxed/simple; bh=EgqlUAEMUi1F0DrEXii/NP0x6x8wIJiHzxz+JMOV3Co=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XneiDRJPj65M1iWz/UntQk1Ovyb0A58fZ6Z0Psy1LZWRulYXYjiEZoF8SvxDwxb30HTRlnDrOddwFxYhxzfAAFNfkKQCb8MQci1m2PJqemGa/4gdHz5XLuAQ6S8e2ow5ozWcMAoyhlifjS5fWb7hUYjeE3omD40+jtnxUY6iGJA= 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=Pp4WNlMZ; arc=none smtp.client-ip=209.85.222.169 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="Pp4WNlMZ" Received: by mail-qk1-f169.google.com with SMTP id af79cd13be357-8ca01dc7d40so469033485a.1 for ; Mon, 16 Mar 2026 07:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1773670047; x=1774274847; 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=NVfS4F3yzp6RxSjfPUPmy97+3JM2QBYP3BC0jY0rHlc=; b=Pp4WNlMZ7HhpDBG71gh4IP4hEERmGLI57wm5epsQ9v+cIxxwOWpSl4ov8JyBf9TOR1 ppU3tw4+fb4Y0SP+5DQ+jQhS8N57fN/RjFLKV3dtNaNYlg4aowhkvs8sVNUPGoR7vBkw xer8TYEy33cjRikzMcOat++yQsW8xFmjIQJw3Mhmp704/rzs4Cv10t7vboRkl7jEXQxB Tr1tZjSH3XMjd4S+JVNiOSnEVD08/Dkq/HJvPFnKyImG3mgPitOoMIXkYSR7RkVkQYsZ N1OaREeV7ldUhjNH6rWbWcT3qXInV4kGnwtix3c1T8XWjwq9rEyXRuaVCVNLHpQqfeYz J5Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773670047; x=1774274847; 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=NVfS4F3yzp6RxSjfPUPmy97+3JM2QBYP3BC0jY0rHlc=; b=M7jBYRqhgCJJzbQ9Xrf2LnWhdHPYFB7lpN/JZNjbIN3AhR/UfSf0ht0l7KJZi0ksyY mDAK0LIIPtmVqHqF6ZPHzkE6fsxidbPEn5zwrW+7ljA6jdGX0kRuADBCoTG15bC7L1vs rlUt6ludoLnDNlYHIw5hSB+WpcZMD3nKNCG2WBfEESM0gyKr9+DRwCtcLHY73GddncTX HMO1YfThCvpPyTmpqbXc+P311H8ACZME/XKUYrkkmzzW2raBJo2qceuJhkRiRLEUyOXJ 5NR+Bx53eBhUkFYVQSlVJafQK1aAkRrzUSDFcXNb+Q1azrPiLdoDKp5sejFS+i6Jhd7o 9psg== X-Forwarded-Encrypted: i=1; AJvYcCXkoRYJee4tJUg9CSfYxuJD1SAzJss5W5cObKaSTsE6mmNiMAwyF+Taf+YEUkjmX+A0wLhK6kzjzTr9EoA=@vger.kernel.org X-Gm-Message-State: AOJu0Yy/MYVs/xzvTgJt+H2ciO6yzOB3D4nNFXkWjlvHHszx/c2yz7il Ha7nUGV8z9024LZ9ALG4HFbVt6Gg76QMiD9fXDqcuzDDHcIEZyEZ5ZDE20MMGB2iT0Q= X-Gm-Gg: ATEYQzylePc8lCNcREHTxo4pBiXYYV5jFp/9IgCppB25+9S7xQvraZ9doXRH95sUyBm BfkV0t3E6yb6+bBYoscW0edtZIlGH7ubZLks4jjq+N7DTtectw0oNmwy4HQvGOROGCt70hdwARn WxltGBmwUI/12ZVcWYErIDBGKkkK3dFfcFJS84K/NpMqikZpQeszDOKWTopR/0FwDq/iDT7kNBM 8T+0pK9UctvQaEqBvaTx81RGOrRYsX+GW1TtzKqkHasYjpmqx9RiQwdz4Cjdjifkp+2jmQ+jvEu mu/MrxwJeg21UUSxi9NjT1DqzUEdOkVi7pc4xzo540+zJVjIYrPfUMzoheQzJM/73OxCYnFIFpM vDKBKsUR3SviFA9+mMrYMocBkS8p2cRjzVo0SQXv2lnKjzUyDDbbg14iJkc2v/CxXrfBD8IXtS2 q4nEqlRZjGrIfg3cohlIpbHT9wf712F0asjLLse5VOFkrvBGQLG63rajh0qfDv7MnvQ0rZteqHV d2El5oEqQ== X-Received: by 2002:ac8:7c4e:0:b0:4ee:280:2e49 with SMTP id d75a77b69052e-50957e9bb88mr168323681cf.66.1773670047327; Mon, 16 Mar 2026 07:07:27 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-50939ec6331sm117733111cf.10.2026.03.16.07.07.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2026 07:07:26 -0700 (PDT) Date: Mon, 16 Mar 2026 10:07:23 -0400 From: Gregory Price To: Lin Ruifeng Cc: akpm@linux-foundation.org, david@kernel.org, ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, ying.huang@linux.alibaba.com, apopple@nvidia.com, joro@8bytes.org, will@kernel.org, robin.murphy@arm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] mm/mempolicy: NUMA mempolicy mismatch during remote access Message-ID: References: <20260316120424.1535575-1-linruifeng4@huawei.com> 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: <20260316120424.1535575-1-linruifeng4@huawei.com> On Mon, Mar 16, 2026 at 08:04:24PM +0800, Lin Ruifeng wrote: > I'd like to report an issue in the SVA I/O Page Fault (IOPF) handling path: > a NUMA memory policy mismatch caused by deferred workqueue processing. > > When hardware triggers a page fault via the IOMMU SVA mechanism, it's handled > asynchronously by a kworker thread. Although the fault handler correctly uses > the original process's mm_struct for address space mapping, the physical page > allocation (e.g., in do_anonymous_page()) still depends on current->mempolicy. > > Since current here is the kworker, not the original user process, any > task-level NUMA policy (e.g., set_mempolicy() or numactl --membind) is > completely ignored. Instead, allocation follows the kworker's default policy, > which may run on a different NUMA node. > > A similar issue was also discussed in [1]. I was wondering if you might have > any suggestions on how to address this issue. > > Link: https://lore.kernel.org/linux-mm/e2d5f3a5-f6f1-4567-a162-a0e814292738@asahilina.net/ > Signed-off-by: Lin Ruifeng > 2.43.0 > I think the best we could do in this scenario is acquire the mm_struct process's mempolicy and plumb it through - but this is not exactly correct either as multiple threads within a process may have different mempolicies. I imagine this also applies to vma policies as well - so you'd need to check both the vma and the task. Not eactly great since we're talking multiple locks where there were none before. ~Gregory