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
prev 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).