All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH 1/2] mm: Abstract THP allocation
@ 2024-09-01  5:02 kernel test robot
  2024-09-02  9:14 ` Dev Jain
  0 siblings, 1 reply; 3+ messages in thread
From: kernel test robot @ 2024-09-01  5:02 UTC (permalink / raw)
  To: oe-kbuild; +Cc: lkp, Dan Carpenter

BCC: lkp@intel.com
CC: oe-kbuild-all@lists.linux.dev
In-Reply-To: <20240830084117.4079805-2-dev.jain@arm.com>
References: <20240830084117.4079805-2-dev.jain@arm.com>
TO: Dev Jain <dev.jain@arm.com>
TO: akpm@linux-foundation.org
TO: david@redhat.com
TO: willy@infradead.org
TO: kirill.shutemov@linux.intel.com
CC: ryan.roberts@arm.com
CC: anshuman.khandual@arm.com
CC: catalin.marinas@arm.com
CC: cl@gentwo.org
CC: vbabka@suse.cz
CC: mhocko@suse.com
CC: apopple@nvidia.com
CC: dave.hansen@linux.intel.com
CC: will@kernel.org
CC: baohua@kernel.org
CC: jack@suse.cz
CC: mark.rutland@arm.com
CC: hughd@google.com
CC: aneesh.kumar@kernel.org
CC: yang@os.amperecomputing.com
CC: peterx@redhat.com
CC: ioworker0@gmail.com
CC: jglisse@google.com
CC: linux-arm-kernel@lists.infradead.org
CC: linux-kernel@vger.kernel.org
CC: linux-mm@kvack.org
CC: Dev Jain <dev.jain@arm.com>

Hi Dev,

kernel test robot noticed the following build warnings:

[auto build test WARNING on akpm-mm/mm-everything]
[also build test WARNING on linus/master v6.11-rc5 next-20240830]
[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/Dev-Jain/mm-Abstract-THP-allocation/20240830-164300
base:   https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-everything
patch link:    https://lore.kernel.org/r/20240830084117.4079805-2-dev.jain%40arm.com
patch subject: [PATCH 1/2] mm: Abstract THP allocation
:::::: branch date: 2 days ago
:::::: commit date: 2 days ago
config: x86_64-randconfig-161-20240901 (https://download.01.org/0day-ci/archive/20240901/202409011215.bhqLigEB-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0

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>
| Reported-by: Dan Carpenter <error27@gmail.com>
| Closes: https://lore.kernel.org/r/202409011215.bhqLigEB-lkp@intel.com/

smatch warnings:
mm/huge_memory.c:1236 __do_huge_pmd_anonymous_page() warn: inconsistent returns 'vmf->ptl'.

vim +1236 mm/huge_memory.c

5ee350d3e6d11e Dev Jain           2024-08-30  1186  
5ee350d3e6d11e Dev Jain           2024-08-30  1187  static vm_fault_t __do_huge_pmd_anonymous_page(struct vm_fault *vmf)
5ee350d3e6d11e Dev Jain           2024-08-30  1188  {
5ee350d3e6d11e Dev Jain           2024-08-30  1189  	struct vm_area_struct *vma = vmf->vma;
5ee350d3e6d11e Dev Jain           2024-08-30  1190  	struct folio *folio = NULL;
5ee350d3e6d11e Dev Jain           2024-08-30  1191  	pgtable_t pgtable;
5ee350d3e6d11e Dev Jain           2024-08-30  1192  	unsigned long haddr = vmf->address & HPAGE_PMD_MASK;
5ee350d3e6d11e Dev Jain           2024-08-30  1193  	vm_fault_t ret = 0;
5ee350d3e6d11e Dev Jain           2024-08-30  1194  	gfp_t gfp = vma_thp_gfp_mask(vma);
5ee350d3e6d11e Dev Jain           2024-08-30  1195  
5ee350d3e6d11e Dev Jain           2024-08-30  1196  	pgtable = pte_alloc_one(vma->vm_mm);
5ee350d3e6d11e Dev Jain           2024-08-30  1197  	if (unlikely(!pgtable)) {
5ee350d3e6d11e Dev Jain           2024-08-30  1198  		ret = VM_FAULT_OOM;
5ee350d3e6d11e Dev Jain           2024-08-30  1199  		goto release;
5ee350d3e6d11e Dev Jain           2024-08-30  1200  	}
5ee350d3e6d11e Dev Jain           2024-08-30  1201  
5ee350d3e6d11e Dev Jain           2024-08-30  1202  	ret = thp_fault_alloc(gfp, HPAGE_PMD_ORDER, vma, haddr, &folio,
5ee350d3e6d11e Dev Jain           2024-08-30  1203  			      vmf->address);
5ee350d3e6d11e Dev Jain           2024-08-30  1204  	if (ret)
5ee350d3e6d11e Dev Jain           2024-08-30  1205  		goto release;
71e3aac0724ffe Andrea Arcangeli   2011-01-13  1206  
82b0f8c39a3869 Jan Kara           2016-12-14  1207  	vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd);
5ee350d3e6d11e Dev Jain           2024-08-30  1208  
82b0f8c39a3869 Jan Kara           2016-12-14  1209  	if (unlikely(!pmd_none(*vmf->pmd))) {
6b31d5955cb29a Michal Hocko       2017-08-18  1210  		goto unlock_release;
71e3aac0724ffe Andrea Arcangeli   2011-01-13  1211  	} else {
6b31d5955cb29a Michal Hocko       2017-08-18  1212  		ret = check_stable_address_space(vma->vm_mm);
6b31d5955cb29a Michal Hocko       2017-08-18  1213  		if (ret)
6b31d5955cb29a Michal Hocko       2017-08-18  1214  			goto unlock_release;
6b31d5955cb29a Michal Hocko       2017-08-18  1215  
6b251fc96cf2cd Andrea Arcangeli   2015-09-04  1216  		/* Deliver the page fault to userland */
6b251fc96cf2cd Andrea Arcangeli   2015-09-04  1217  		if (userfaultfd_missing(vma)) {
82b0f8c39a3869 Jan Kara           2016-12-14  1218  			spin_unlock(vmf->ptl);
cfe3236d32d07b Kefeng Wang        2023-03-02  1219  			folio_put(folio);
bae473a423f65e Kirill A. Shutemov 2016-07-26  1220  			pte_free(vma->vm_mm, pgtable);
8fd5eda4c7268b Miaohe Lin         2021-05-04  1221  			ret = handle_userfault(vmf, VM_UFFD_MISSING);
8fd5eda4c7268b Miaohe Lin         2021-05-04  1222  			VM_BUG_ON(ret & VM_FAULT_FALLBACK);
8fd5eda4c7268b Miaohe Lin         2021-05-04  1223  			return ret;
6b251fc96cf2cd Andrea Arcangeli   2015-09-04  1224  		}
5ee350d3e6d11e Dev Jain           2024-08-30  1225  		map_pmd_thp(folio, vmf, vma, haddr, pgtable);
71e3aac0724ffe Andrea Arcangeli   2011-01-13  1226  	}
71e3aac0724ffe Andrea Arcangeli   2011-01-13  1227  
aa2e878efa7949 David Rientjes     2012-05-29  1228  	return 0;
6b31d5955cb29a Michal Hocko       2017-08-18  1229  unlock_release:
6b31d5955cb29a Michal Hocko       2017-08-18  1230  	spin_unlock(vmf->ptl);
6b31d5955cb29a Michal Hocko       2017-08-18  1231  release:
6b31d5955cb29a Michal Hocko       2017-08-18  1232  	if (pgtable)
6b31d5955cb29a Michal Hocko       2017-08-18  1233  		pte_free(vma->vm_mm, pgtable);
5ee350d3e6d11e Dev Jain           2024-08-30  1234  	if (folio)
cfe3236d32d07b Kefeng Wang        2023-03-02  1235  		folio_put(folio);
6b31d5955cb29a Michal Hocko       2017-08-18 @1236  	return ret;
6b31d5955cb29a Michal Hocko       2017-08-18  1237  

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

^ permalink raw reply	[flat|nested] 3+ messages in thread
* [PATCH 0/2] Do not shatter hugezeropage on wp-fault
@ 2024-08-30  8:41 Dev Jain
  2024-08-30  8:41 ` [PATCH 1/2] mm: Abstract THP allocation Dev Jain
  0 siblings, 1 reply; 3+ messages in thread
From: Dev Jain @ 2024-08-30  8:41 UTC (permalink / raw)
  To: akpm, david, willy, kirill.shutemov
  Cc: ryan.roberts, anshuman.khandual, catalin.marinas, cl, vbabka,
	mhocko, apopple, dave.hansen, will, baohua, jack, mark.rutland,
	hughd, aneesh.kumar, yang, peterx, ioworker0, jglisse,
	linux-arm-kernel, linux-kernel, linux-mm, Dev Jain

It was observed at [1] and [2] that the current kernel behaviour of
shattering a hugezeropage is inconsistent and suboptimal. For a VMA with
a THP allowable order, when we write-fault on it, the kernel installs a
PMD-mapped THP. On the other hand, if we first get a read fault, we get
a PMD pointing to the hugezeropage; subsequent write will trigger a
write-protection fault, shattering the hugezeropage into one writable
page, and all the other PTEs write-protected. The conclusion being, as
compared to the case of a single write-fault, applications have to suffer
512 extra page faults if they were to use the VMA as such, plus we get
the overhead of khugepaged trying to replace that area with a THP anyway.

Instead, replace the hugezeropage with a THP on wp-fault.

[1]: https://lore.kernel.org/all/3743d7e1-0b79-4eaf-82d5-d1ca29fe347d@arm.com/
[2]: https://lore.kernel.org/all/1cfae0c0-96a2-4308-9c62-f7a640520242@arm.com/

Dev Jain (2):
  mm: Abstract THP allocation
  mm: Allocate THP on hugezeropage wp-fault

 include/linux/huge_mm.h |   7 ++
 mm/huge_memory.c        | 171 +++++++++++++++++++++++++++++-----------
 mm/memory.c             |   5 +-
 3 files changed, 136 insertions(+), 47 deletions(-)

-- 
2.30.2



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-09-02  9:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-01  5:02 [PATCH 1/2] mm: Abstract THP allocation kernel test robot
2024-09-02  9:14 ` Dev Jain
  -- strict thread matches above, loose matches on Subject: below --
2024-08-30  8:41 [PATCH 0/2] Do not shatter hugezeropage on wp-fault Dev Jain
2024-08-30  8:41 ` [PATCH 1/2] mm: Abstract THP allocation Dev Jain

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.