All of lore.kernel.org
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Bharata B Rao <bharata@amd.com>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev
Subject: Re: [RFC PATCH 1/2] sched/numa: Fault count based NUMA hint fault latency
Date: Sat, 30 Mar 2024 11:47:22 +0800	[thread overview]
Message-ID: <202403301111.fNcnRPWz-lkp@intel.com> (raw)
In-Reply-To: <20240327160237.2355-2-bharata@amd.com>

Hi Bharata,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on peterz-queue/sched/core]
[also build test ERROR on linus/master v6.9-rc1 next-20240328]
[cannot apply to akpm-mm/mm-everything tip/sched/core]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Bharata-B-Rao/sched-numa-Fault-count-based-NUMA-hint-fault-latency/20240328-000607
base:   https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git sched/core
patch link:    https://lore.kernel.org/r/20240327160237.2355-2-bharata%40amd.com
patch subject: [RFC PATCH 1/2] sched/numa: Fault count based NUMA hint fault latency
config: arm-defconfig (https://download.01.org/0day-ci/archive/20240330/202403301111.fNcnRPWz-lkp@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project.git f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240330/202403301111.fNcnRPWz-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202403301111.fNcnRPWz-lkp@intel.com/

All errors (new ones prefixed by >>):

>> mm/memory.c:4804:26: error: no member named 'hint_faults' in 'struct mm_struct'
           atomic_inc(&vma->vm_mm->hint_faults);
                       ~~~~~~~~~~  ^
   1 error generated.
--
>> mm/mprotect.c:163:33: error: no member named 'hint_faults' in 'struct mm_struct'
                                                           atomic_read(&vma->vm_mm->hint_faults));
                                                                        ~~~~~~~~~~  ^
   1 error generated.


vim +4804 mm/memory.c

  4792	
  4793	static vm_fault_t do_numa_page(struct vm_fault *vmf)
  4794	{
  4795		struct vm_area_struct *vma = vmf->vma;
  4796		struct folio *folio = NULL;
  4797		int nid = NUMA_NO_NODE;
  4798		bool writable = false;
  4799		int last_cpupid;
  4800		int target_nid;
  4801		pte_t pte, old_pte;
  4802		int flags = 0;
  4803	
> 4804		atomic_inc(&vma->vm_mm->hint_faults);
  4805	
  4806		/*
  4807		 * The "pte" at this point cannot be used safely without
  4808		 * validation through pte_unmap_same(). It's of NUMA type but
  4809		 * the pfn may be screwed if the read is non atomic.
  4810		 */
  4811		spin_lock(vmf->ptl);
  4812		if (unlikely(!pte_same(ptep_get(vmf->pte), vmf->orig_pte))) {
  4813			pte_unmap_unlock(vmf->pte, vmf->ptl);
  4814			goto out;
  4815		}
  4816	
  4817		/* Get the normal PTE  */
  4818		old_pte = ptep_get(vmf->pte);
  4819		pte = pte_modify(old_pte, vma->vm_page_prot);
  4820	
  4821		/*
  4822		 * Detect now whether the PTE could be writable; this information
  4823		 * is only valid while holding the PT lock.
  4824		 */
  4825		writable = pte_write(pte);
  4826		if (!writable && vma_wants_manual_pte_write_upgrade(vma) &&
  4827		    can_change_pte_writable(vma, vmf->address, pte))
  4828			writable = true;
  4829	
  4830		folio = vm_normal_folio(vma, vmf->address, pte);
  4831		if (!folio || folio_is_zone_device(folio))
  4832			goto out_map;
  4833	
  4834		/* TODO: handle PTE-mapped THP */
  4835		if (folio_test_large(folio))
  4836			goto out_map;
  4837	
  4838		/*
  4839		 * Avoid grouping on RO pages in general. RO pages shouldn't hurt as
  4840		 * much anyway since they can be in shared cache state. This misses
  4841		 * the case where a mapping is writable but the process never writes
  4842		 * to it but pte_write gets cleared during protection updates and
  4843		 * pte_dirty has unpredictable behaviour between PTE scan updates,
  4844		 * background writeback, dirty balancing and application behaviour.
  4845		 */
  4846		if (!writable)
  4847			flags |= TNF_NO_GROUP;
  4848	
  4849		/*
  4850		 * Flag if the folio is shared between multiple address spaces. This
  4851		 * is later used when determining whether to group tasks together
  4852		 */
  4853		if (folio_estimated_sharers(folio) > 1 && (vma->vm_flags & VM_SHARED))
  4854			flags |= TNF_SHARED;
  4855	
  4856		nid = folio_nid(folio);
  4857		/*
  4858		 * For memory tiering mode, cpupid of slow memory page is used
  4859		 * to record page access time.  So use default value.
  4860		 */
  4861		if ((sysctl_numa_balancing_mode & NUMA_BALANCING_MEMORY_TIERING) &&
  4862		    !node_is_toptier(nid))
  4863			last_cpupid = (-1 & LAST_CPUPID_MASK);
  4864		else
  4865			last_cpupid = folio_last_cpupid(folio);
  4866		target_nid = numa_migrate_prep(folio, vma, vmf->address, nid, &flags);
  4867		if (target_nid == NUMA_NO_NODE) {
  4868			folio_put(folio);
  4869			goto out_map;
  4870		}
  4871		pte_unmap_unlock(vmf->pte, vmf->ptl);
  4872		writable = false;
  4873	
  4874		/* Migrate to the requested node */
  4875		if (migrate_misplaced_folio(folio, vma, target_nid)) {
  4876			nid = target_nid;
  4877			flags |= TNF_MIGRATED;
  4878		} else {
  4879			flags |= TNF_MIGRATE_FAIL;
  4880			vmf->pte = pte_offset_map_lock(vma->vm_mm, vmf->pmd,
  4881						       vmf->address, &vmf->ptl);
  4882			if (unlikely(!vmf->pte))
  4883				goto out;
  4884			if (unlikely(!pte_same(ptep_get(vmf->pte), vmf->orig_pte))) {
  4885				pte_unmap_unlock(vmf->pte, vmf->ptl);
  4886				goto out;
  4887			}
  4888			goto out_map;
  4889		}
  4890	
  4891	out:
  4892		if (nid != NUMA_NO_NODE)
  4893			task_numa_fault(last_cpupid, nid, 1, flags);
  4894		return 0;
  4895	out_map:
  4896		/*
  4897		 * Make it present again, depending on how arch implements
  4898		 * non-accessible ptes, some can allow access by kernel mode.
  4899		 */
  4900		old_pte = ptep_modify_prot_start(vma, vmf->address, vmf->pte);
  4901		pte = pte_modify(old_pte, vma->vm_page_prot);
  4902		pte = pte_mkyoung(pte);
  4903		if (writable)
  4904			pte = pte_mkwrite(pte, vma);
  4905		ptep_modify_prot_commit(vma, vmf->address, vmf->pte, old_pte, pte);
  4906		update_mmu_cache_range(vmf, vma, vmf->address, vmf->pte, 1);
  4907		pte_unmap_unlock(vmf->pte, vmf->ptl);
  4908		goto out;
  4909	}
  4910	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

  parent reply	other threads:[~2024-03-30  3:48 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27 16:02 [RFC PATCH 0/2] Hot page promotion optimization for large address space Bharata B Rao
2024-03-27 16:02 ` [RFC PATCH 1/2] sched/numa: Fault count based NUMA hint fault latency Bharata B Rao
2024-03-28  1:56   ` Huang, Ying
2024-03-28  4:39     ` Bharata B Rao
2024-03-28  5:21       ` Huang, Ying
2024-03-30  1:11   ` kernel test robot
2024-03-30  3:47   ` kernel test robot [this message]
2024-03-27 16:02 ` [RFC PATCH 2/2] mm: Update hint fault count for pages that are skipped during scanning Bharata B Rao
2024-03-28  5:35 ` [RFC PATCH 0/2] Hot page promotion optimization for large address space Huang, Ying
2024-03-28  5:49   ` Bharata B Rao
2024-03-28  6:03     ` Huang, Ying
2024-03-28  6:29       ` Bharata B Rao
2024-03-29  1:14         ` Huang, Ying
2024-04-01 12:20           ` Bharata B Rao
2024-04-02  2:03             ` Huang, Ying
2024-04-02  9:26               ` Bharata B Rao
2024-04-03  8:40                 ` Huang, Ying
2024-04-12  4:00                   ` Bharata B Rao
2024-04-12  7:28                     ` Huang, Ying
2024-04-12  8:16                       ` Bharata B Rao
2024-04-12  8:48                         ` Huang, Ying

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202403301111.fNcnRPWz-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=bharata@amd.com \
    --cc=llvm@lists.linux.dev \
    --cc=oe-kbuild-all@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.