oe-kbuild-all.lists.linux.dev archive mirror
 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: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240327160237.2355-2-bharata@amd.com>
2024-03-30  1:11 ` [RFC PATCH 1/2] sched/numa: Fault count based NUMA hint fault latency kernel test robot
2024-03-30  3:47 ` kernel test robot [this message]

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).