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