From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) (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 54B1138C43A for ; Thu, 12 Mar 2026 16:31:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773333104; cv=none; b=VBvwk/gwYNyj+AdmJ8uvw/EsLnRYDSeFSUmMURfMdw2qrPDoHYHgLGVZO5UMNmPIUp0IoWAad4TE6lwYdmuSEDKuebkkRKhvFSgxUv7v+420VidLyfmCfIpp+nnY38Rlx+ZWM+4nT64AbruaQtkLNQRc1dFqTRJNsOct2ZrDdNs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773333104; c=relaxed/simple; bh=pfIgyP/P46TT0djpT/bGNwntekcBGLuYfgq4G9/RzGA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eoaBOK6Fh36Y0900xLRdOE+XKHWVbAciDJfe632OfLhuW/hRxi2UNvK3zaLg/QXtBercdTscLC2f/bQXegoGAK0jTYOOFVoTaDyO9F92sVL9IxrY/kn7ZreCs3qPHEkR8Vt0ugL6oKRpLDV/YF1nSGim2eFBLLxKgpfsp2SensY= 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=gATMl/pV; arc=none smtp.client-ip=209.85.222.170 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="gATMl/pV" Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-8cd8576a512so245679985a.0 for ; Thu, 12 Mar 2026 09:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1773333100; x=1773937900; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=sTldllX6d0omLBgu0LmuFrBJpxfhsmTLRlWR1u3QCOg=; b=gATMl/pVoZJkhfoe7q1A67QZR+c+QqW+O9PZRjgLDyHtHsRCpBqP+RWACR5s0QJqK8 W7mLMZv4JcITFYMA22ZrC9PeGtfCYHTkQPlvTIoHK/CQJFTKq4PUEfM/LCzuhD3+Sx5t ifcDOmoq314wS1va6RA7zmu6V5xdQygNh3Yjxdrx0RKuj3nO4GQX6aAuIDJbRJzR8p4l qPeQQ1ORkA4pf4LQvA94m47LJKnKyNP/WcULGI9W34QtJt6tPi+E/Gw3t45H8pWF/UsL 76MbOCfAf4qB2JNjoPOSXx0c4VmXMOyD41Km5wGCLdLCTh88Beqg+n1dvxTjSRZn96hS 5Wwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773333100; x=1773937900; h=in-reply-to:content-transfer-encoding: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=sTldllX6d0omLBgu0LmuFrBJpxfhsmTLRlWR1u3QCOg=; b=L0zofzBb0xCbYozc6OYEor7dW2pBxuxzajRSDCey+d5zi4rQdtzoSiMmO6/8APZp1i Yh/CfUrT62pPhJixSPrTKcP9mig+lvbdjLq+SbuAHbLVfHOZh2Qq4Dq+SYZJC10IFzSN YZONitLcVLaxPUJjF7D+75NkhIOVNGOSk6hIJG2GrYaApJ/hF9+IZVxclJkvYzXnJk0Q Cs152Igrvgps+ZC8khmmM71VImEztiOOm69gwJzkJq4p7MZnRKy05wpOm+GOzi2SY97F mZx5N+udxAQWPgXgcQa9dSGBOcmFuiXitXKOc37Q5+Nrls19XRJ4GRoaxoYFkzTQyWq1 OCEQ== X-Forwarded-Encrypted: i=1; AJvYcCW67f9/wyMU5bNx+gfu/tC/NtGIxqY+JKnuw9VCm/30jarabHA3Urt959334PfOIANN3+D812ojS2VhwXQ=@vger.kernel.org X-Gm-Message-State: AOJu0Ywe3rOWbU+V29aU1cO/jPfmcYw/yIQiEoFZOrhzwWO6DAOa/fXh h05kDqYmfZUFl6cn0xEYMLKJhMiKpbZnLsU2rGuVNPOn2qIBPiqbqVnjbdHSO7ad2FA= X-Gm-Gg: ATEYQzzPHV/kvx6CGJMtLS3ShbHvg57oGTc00+Ay32WZb7AFvG2QFYiJyCfDrqyQsJN lC+iZ/fEgnBwtvjaWqugj+PFFJg8jZ/ClGjuV2tUWyc2TvTV13WjvCSbBT04JBJNLhb3aowrlMF /H+LuiKGOVhFoFpM7IB6E0bdrzlj1c1jBZtWfP5GBJO7XtPKQxB2U+o1H4F6Id0nqOQ8LAAnUPv r4Qmiw7WVKrAGeg64+v8d1eTREAheWe8jWGG7JdoqxjPD9BKlIc92ddiIdvakb3l62wxnoEXHP/ EbLrjUNgxkSyXND6K4jYCe4VVnonkyXfhHjT0ipIllg8CzC525Q7n79MzXvUqr3upluTqRSxbjF bDmD5afnAF8TviY9FpvVnwFWEtwROGv7QFy//5cBa+suzjrfwUGzHrgvpcGlOtBrpsv8wVkh99E xeiAmngcN+nMM6qjK/5oGE2ZwLTupALq6dOoTo+LSbe9Ai4aNotQ6WFJLDsdw0JoZzuQlhm+t72 +JCKhTAAA== X-Received: by 2002:a05:620a:1711:b0:8cd:9584:632a with SMTP id af79cd13be357-8cdaa8ab027mr479259385a.41.1773333100079; Thu, 12 Mar 2026 09:31:40 -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 af79cd13be357-8cda210d972sm417972985a.28.2026.03.12.09.31.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Mar 2026 09:31:39 -0700 (PDT) Date: Thu, 12 Mar 2026 12:31:37 -0400 From: Gregory Price To: Riwan Cc: "Andrew Morton (maintainer:MEMORY MANAGEMENT - RMAP (REVERSE MAPPING))" , "David Hildenbrand (maintainer:MEMORY MANAGEMENT - RMAP (REVERSE MAPPING))" , "Lorenzo Stoakes (maintainer:MEMORY MANAGEMENT - RMAP (REVERSE MAPPING))" , "Rik van Riel (reviewer:MEMORY MANAGEMENT - RMAP (REVERSE MAPPING))" , "Liam R. Howlett (reviewer:MEMORY MANAGEMENT - RMAP (REVERSE MAPPING))" , "Vlastimil Babka (reviewer:MEMORY MANAGEMENT - RMAP (REVERSE MAPPING))" , "Harry Yoo (reviewer:MEMORY MANAGEMENT - RMAP (REVERSE MAPPING))" , "Jann Horn (reviewer:MEMORY MANAGEMENT - RMAP (REVERSE MAPPING))" , "Zi Yan (reviewer:MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION)" , "Matthew Brost (reviewer:MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION)" , "Joshua Hahn (reviewer:MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION)" , "Rakie Kim (reviewer:MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION)" , "Byungchul Park (reviewer:MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION)" , "Ying Huang (reviewer:MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION)" , "Alistair Popple (reviewer:MEMORY MANAGEMENT - MEMORY POLICY AND MIGRATION)" , "open list:MEMORY MANAGEMENT - RMAP (REVERSE MAPPING)" , open list Subject: Re: mm/rmap: Should vma_migratable be checked in try_to_migrate_one? Message-ID: References: <83E1B606-C461-4FC1-BFF8-FC2BEFDCE2B6@gmail.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <83E1B606-C461-4FC1-BFF8-FC2BEFDCE2B6@gmail.com> On Wed, Mar 11, 2026 at 02:46:55PM +0100, Riwan wrote: > Hi, I’m a phd student working on memory management and I have the following question: > Is it intentional to not check for `vma_migratable` in `try_to_migrate_one` ? > If the vma is not migratable, it would be logical to cancel the page migration at this point. > > From what I understand, `vma_migratable` is called to check if a pages in a specific VMA can be migrated or not. > From what I can see, user-facing migration paths (mbind, move_pages) and NUMA balancing already check wether migration is possible or not with `vma_migratable`, but other migration path, such as compaction with kcompactd, ignore this check. > As `try_to_migrate_one` is the only place where we have access to the vma (due to reverse mapping), it would be logical to check here for `vma_migratable` (before we only have access to the folio). > > I’m still new to the Linux Kernel, and may have missed critical subsystem / behavior, and I would be curious to know if this was overlooked or if there is a reason behind not calling `vma_migratable`. > > From what I could get, here is the relevant context: > - Implem of vma_migratable : mm/mempolicy: check hugepage migration is supported by arch in vma_migratable() (https://lore.kernel.org/all/20200402041052.Y4zsoYman%25akpm@linux-foundation.org/) > - Implem of try_to_migrate_one, previously managed in try_to_unmap_one : mm/rmap: split migration into its own function (https://lore.kernel.org/all/20210701015416.0t4MkxtDR%25akpm@linux-foundation.org/) > Cursory look, it appears that vma_migratable is intended as a shortcut to determine if an entire given VMA is otherwise not eligible for migration (if it's backed by dax, then it's assumed the data should just live there always and forever). This is different than kcompact and others which touch individual folios - but will have different ways to determine the same thing. If you're just trying to migrate one folio, you can get everything you need mostly from the folio's flags, and so most of the callers you're concerned about most likely do eactly this. ~Gregory