linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the akpm-current tree with the folio tree
@ 2021-07-21  6:31 Stephen Rothwell
  2021-09-06  4:48 ` Stephen Rothwell
  0 siblings, 1 reply; 24+ messages in thread
From: Stephen Rothwell @ 2021-07-21  6:31 UTC (permalink / raw)
  To: Andrew Morton, Matthew Wilcox
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Suren Baghdasaryan

[-- Attachment #1: Type: text/plain, Size: 6202 bytes --]

Hi all,

Today's linux-next merge of the akpm-current tree got conflicts in:

  include/linux/memcontrol.h
  mm/memcontrol.c

between commits:

  05bb7bbab428 ("mm/memcg: Convert mem_cgroup_charge() to take a folio")
  8b2afb6a1c34 ("mm/memcg: Convert mem_cgroup_uncharge() to take a folio")

from the folio tree and commit:

  1f4c6a1cf274 ("mm, memcg: inline mem_cgroup_{charge/uncharge} to improve disabled memcg config")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/memcontrol.h
index af9c44bb1e42,406058a0c480..000000000000
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@@ -704,15 -691,37 +702,36 @@@ static inline bool mem_cgroup_below_min
  		page_counter_read(&memcg->memory);
  }
  
- int mem_cgroup_charge(struct folio *folio, struct mm_struct *mm, gfp_t gfp);
 -int __mem_cgroup_charge(struct page *page, struct mm_struct *mm,
 -			gfp_t gfp_mask);
 -static inline int mem_cgroup_charge(struct page *page, struct mm_struct *mm,
 -				    gfp_t gfp_mask)
++int __mem_cgroup_charge(struct folio *folio, struct mm_struct *mm, gfp_t gfp);
++static inline int mem_cgroup_charge(struct folio *folio, struct mm_struct *mm,
++				    gfp_t gfp)
+ {
+ 	if (mem_cgroup_disabled())
+ 		return 0;
 -	return __mem_cgroup_charge(page, mm, gfp_mask);
++	return __mem_cgroup_charge(folio, mm, gfp);
+ }
+ 
  int mem_cgroup_swapin_charge_page(struct page *page, struct mm_struct *mm,
  				  gfp_t gfp, swp_entry_t entry);
  void mem_cgroup_swapin_uncharge_swap(swp_entry_t entry);
  
- void mem_cgroup_uncharge(struct folio *folio);
- void mem_cgroup_uncharge_list(struct list_head *page_list);
 -void __mem_cgroup_uncharge(struct page *page);
 -static inline void mem_cgroup_uncharge(struct page *page)
++void __mem_cgroup_uncharge(struct folio *folio);
++static inline void mem_cgroup_uncharge(struct folio *folio)
+ {
+ 	if (mem_cgroup_disabled())
+ 		return;
 -	__mem_cgroup_uncharge(page);
++	__mem_cgroup_uncharge(folio);
+ }
+ 
+ void __mem_cgroup_uncharge_list(struct list_head *page_list);
+ static inline void mem_cgroup_uncharge_list(struct list_head *page_list)
+ {
+ 	if (mem_cgroup_disabled())
+ 		return;
+ 	__mem_cgroup_uncharge_list(page_list);
+ }
  
 -void mem_cgroup_migrate(struct page *oldpage, struct page *newpage);
 +void mem_cgroup_migrate(struct folio *old, struct folio *new);
  
  /**
   * mem_cgroup_lruvec - get the lru list vector for a memcg & node
diff --cc mm/memcontrol.c
index 1d77c873463c,c010164172dd..000000000000
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -6712,29 -6718,27 +6708,26 @@@ out
  }
  
  /**
-  * mem_cgroup_charge - Charge a newly allocated folio to a cgroup.
 - * __mem_cgroup_charge - charge a newly allocated page to a cgroup
 - * @page: page to charge
 - * @mm: mm context of the victim
 - * @gfp_mask: reclaim mode
++ * __mem_cgroup_charge - Charge a newly allocated folio to a cgroup.
 + * @folio: Folio to charge.
 + * @mm: mm context of the allocating task.
 + * @gfp: Reclaim mode.
   *
 - * Try to charge @page to the memcg that @mm belongs to, reclaiming
 - * pages according to @gfp_mask if necessary. if @mm is NULL, try to
 + * Try to charge @folio to the memcg that @mm belongs to, reclaiming
 + * pages according to @gfp if necessary.  If @mm is NULL, try to
   * charge to the active memcg.
   *
 - * Do not use this for pages allocated for swapin.
 + * Do not use this for folios allocated for swapin.
   *
 - * Returns 0 on success. Otherwise, an error code is returned.
 + * Return: 0 on success. Otherwise, an error code is returned.
   */
- int mem_cgroup_charge(struct folio *folio, struct mm_struct *mm, gfp_t gfp)
 -int __mem_cgroup_charge(struct page *page, struct mm_struct *mm,
 -			gfp_t gfp_mask)
++int __mem_cgroup_charge(struct folio *folio, struct mm_struct *mm, gfp_t gfp)
  {
  	struct mem_cgroup *memcg;
  	int ret;
  
- 	if (mem_cgroup_disabled())
- 		return 0;
- 
  	memcg = get_mem_cgroup_from_mm(mm);
 -	ret = charge_memcg(page, memcg, gfp_mask);
 +	ret = charge_memcg(folio, memcg, gfp);
  	css_put(&memcg->css);
  
  	return ret;
@@@ -6906,20 -6909,17 +6899,17 @@@ static void uncharge_folio(struct foli
  }
  
  /**
-  * mem_cgroup_uncharge - Uncharge a folio.
 - * __mem_cgroup_uncharge - uncharge a page
 - * @page: page to uncharge
++ * __mem_cgroup_uncharge - Uncharge a folio.
 + * @folio: Folio to uncharge.
   *
 - * Uncharge a page previously charged with __mem_cgroup_charge().
 + * Uncharge a folio previously charged with mem_cgroup_charge().
   */
- void mem_cgroup_uncharge(struct folio *folio)
 -void __mem_cgroup_uncharge(struct page *page)
++void __mem_cgroup_uncharge(struct folio *folio)
  {
  	struct uncharge_gather ug;
  
- 	if (mem_cgroup_disabled())
- 		return;
- 
 -	/* Don't touch page->lru of any random page, pre-check: */
 -	if (!page_memcg(page))
 +	/* Don't touch folio->lru of any random page, pre-check: */
 +	if (!folio_memcg(folio))
  		return;
  
  	uncharge_gather_clear(&ug);
@@@ -6932,19 -6932,16 +6922,16 @@@
   * @page_list: list of pages to uncharge
   *
   * Uncharge a list of pages previously charged with
-  * mem_cgroup_charge().
+  * __mem_cgroup_charge().
   */
- void mem_cgroup_uncharge_list(struct list_head *page_list)
+ void __mem_cgroup_uncharge_list(struct list_head *page_list)
  {
  	struct uncharge_gather ug;
 -	struct page *page;
 +	struct folio *folio;
  
- 	if (mem_cgroup_disabled())
- 		return;
- 
  	uncharge_gather_clear(&ug);
 -	list_for_each_entry(page, page_list, lru)
 -		uncharge_page(page, &ug);
 +	list_for_each_entry(folio, page_list, lru)
 +		uncharge_folio(folio, &ug);
  	if (ug.memcg)
  		uncharge_batch(&ug);
  }

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread
* linux-next: manual merge of the akpm-current tree with the folio tree
@ 2022-04-08  5:18 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2022-04-08  5:18 UTC (permalink / raw)
  To: Andrew Morton, Matthew Wilcox
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Miaohe Lin, Zi Yan

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/migrate.c

between commits:

  ffe06786b540 ("mm/migrate: Use a folio in alloc_migration_target()")
  c185e494ae0c ("mm/migrate: Use a folio in migrate_misplaced_transhuge_page()")

from the folio tree and commits:

  c5b406e86042 ("mm: migrate: use thp_order instead of HPAGE_PMD_ORDER for new page allocation.")
  649b74d8bc1a ("mm/migration: fix the confusing PageTransHuge check")
  6c9c6f6b597d ("mm/migration: remove unneeded out label")

from the akpm-current tree.

I fixed it up (I used the former changes) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread
* linux-next: manual merge of the akpm-current tree with the folio tree
@ 2022-04-08  5:08 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2022-04-08  5:08 UTC (permalink / raw)
  To: Andrew Morton, Matthew Wilcox
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Zi Yan

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/mempolicy.c

between commit:

  ec4858e07ed6 ("mm/mempolicy: Use vma_alloc_folio() in new_page()")

from the folio tree and commit:

  c5b406e86042 ("mm: migrate: use thp_order instead of HPAGE_PMD_ORDER for new page allocation.")

from the akpm-current tree.

I fixed it up (I just ued the former change) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread
* linux-next: manual merge of the akpm-current tree with the folio tree
@ 2022-03-22  8:35 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2022-03-22  8:35 UTC (permalink / raw)
  To: Andrew Morton, Matthew Wilcox
  Cc: Linux Kernel Mailing List, Linux Next Mailing List, Michal Hocko

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/internal.h

between commit:

  ece1ed7bfa12 ("mm/gup: Add try_get_folio() and try_grab_folio()")

from the folio tree and commit:

  c5a8dccce9cd ("mm: handle uninitialized numa nodes gracefully")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/internal.h
index 293eca1360dc,dd42be01e628..000000000000
--- a/mm/internal.h
+++ b/mm/internal.h
@@@ -752,11 -713,6 +747,13 @@@ void vunmap_range_noflush(unsigned lon
  int numa_migrate_prep(struct page *page, struct vm_area_struct *vma,
  		      unsigned long addr, int page_nid, int *flags);
  
 +void free_zone_device_page(struct page *page);
 +
 +/*
 + * mm/gup.c
 + */
 +struct folio *try_grab_folio(struct page *page, int refs, unsigned int flags);
 +
+ DECLARE_PER_CPU(struct per_cpu_nodestat, boot_nodestats);
+ 
  #endif	/* __MM_INTERNAL_H */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread
* linux-next: manual merge of the akpm-current tree with the folio tree
@ 2022-02-16  6:15 Stephen Rothwell
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen Rothwell @ 2022-02-16  6:15 UTC (permalink / raw)
  To: Andrew Morton, Matthew Wilcox (Oracle)
  Cc: Alex Sierra, Alistair Popple, Christoph Hellwig,
	Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 5283 bytes --]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/gup.c

between commit:

  024d57c2766e ("mm/gup: Convert check_and_migrate_movable_pages() to use a folio")

from the folio tree and commits:

  d4dddc8ac982 ("mm: refactor check_and_migrate_movable_pages")
  2bba8945c42e ("mm/gup: fail get_user_pages for LONGTERM dev coherent type")
  de09ea3e8f88 ("mm/gup: migrate device coherent pages when pinning instead of failing")

from the akpm-current tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/gup.c
index 57bf69ac8ab4,4ab43b4fc9bc..000000000000
--- a/mm/gup.c
+++ b/mm/gup.c
@@@ -1783,50 -1844,84 +1786,85 @@@ static long check_and_migrate_movable_p
  					    struct page **pages,
  					    unsigned int gup_flags)
  {
- 	unsigned long i;
- 	unsigned long isolation_error_count = 0;
- 	bool drain_allow = true;
+ 	unsigned long isolation_error_count = 0, i;
 -	struct page *prev_head = NULL;
++	struct folio *prev_folio = NULL;
  	LIST_HEAD(movable_page_list);
- 	long ret = 0;
- 	struct folio *folio, *prev_folio = NULL;
- 	struct migration_target_control mtc = {
- 		.nid = NUMA_NO_NODE,
- 		.gfp_mask = GFP_USER | __GFP_NOWARN,
- 	};
+ 	bool drain_allow = true;
+ 	int ret = 0;
  
  	for (i = 0; i < nr_pages; i++) {
- 		folio = page_folio(pages[i]);
 -		struct page *head = compound_head(pages[i]);
++		struct folio *folio = page_folio(pages[i]);
+ 
 -		if (head == prev_head)
 +		if (folio == prev_folio)
  			continue;
 -		prev_head = head;
 +		prev_folio = folio;
+ 
  		/*
- 		 * If we get a movable page, since we are going to be pinning
- 		 * these entries, try to move them out if possible.
+ 		 * Device private pages will get faulted in during gup so it
+ 		 * shouldn't be possible to see one here.
  		 */
- 		if (!is_pinnable_page(&folio->page)) {
- 			if (folio_test_hugetlb(folio)) {
- 				if (!isolate_huge_page(&folio->page,
- 							&movable_page_list))
- 					isolation_error_count++;
- 			} else {
- 				if (!folio_test_lru(folio) && drain_allow) {
- 					lru_add_drain_all();
- 					drain_allow = false;
- 				}
 -		if (WARN_ON_ONCE(is_device_private_page(head))) {
++		if (WARN_ON_ONCE(is_device_private_page(&folio->page))) {
+ 			ret = -EFAULT;
+ 			goto unpin_pages;
+ 		}
  
- 				if (folio_isolate_lru(folio)) {
- 					isolation_error_count++;
- 					continue;
- 				}
- 				list_add_tail(&folio->lru, &movable_page_list);
- 				node_stat_mod_folio(folio,
- 						    NR_ISOLATED_ANON +
- 						    folio_is_file_lru(folio),
- 						    folio_nr_pages(folio));
+ 		/*
+ 		 * Device coherent pages are managed by a driver and should not
+ 		 * be pinned indefinitely as it prevents the driver moving the
+ 		 * page. So when trying to pin with FOLL_LONGTERM instead try
+ 		 * to migrate the page out of device memory.
+ 		 */
 -		if (is_device_coherent_page(head)) {
 -			WARN_ON_ONCE(PageCompound(head));
++		if (is_device_coherent_page(&folio->page)) {
++			WARN_ON_ONCE(PageCompound(&folio->page));
+ 
+ 			/*
+ 			 * Migration will fail if the page is pinned, so convert
+ 			 * the pin on the source page to a normal reference.
+ 			 */
+ 			if (gup_flags & FOLL_PIN) {
 -				get_page(head);
 -				unpin_user_page(head);
++				get_page(&folio->page);
++				unpin_user_page(&folio->page);
  			}
+ 
 -			pages[i] = migrate_device_page(head, gup_flags);
++			pages[i] = migrate_device_page(&folio->page, gup_flags);
+ 			if (!pages[i]) {
+ 				ret = -EBUSY;
+ 				goto unpin_pages;
+ 			}
+ 			continue;
  		}
+ 
 -		if (is_pinnable_page(head))
++		if (is_pinnable_page(&folio->page))
+ 			continue;
+ 
+ 		/*
+ 		 * Try to move out any movable page before pinning the range.
+ 		 */
 -		if (PageHuge(head)) {
 -			if (!isolate_huge_page(head, &movable_page_list))
++		if (folio_test_hugetlb(folio)) {
++			if (!isolate_huge_page(&folio->page,
++					       &movable_page_list))
+ 				isolation_error_count++;
+ 			continue;
+ 		}
+ 
 -		if (!PageLRU(head) && drain_allow) {
++		if (!folio_test_lru(folio) && drain_allow) {
+ 			lru_add_drain_all();
+ 			drain_allow = false;
+ 		}
+ 
 -		if (isolate_lru_page(head)) {
++		if (folio_isolate_lru(folio)) {
+ 			isolation_error_count++;
+ 			continue;
+ 		}
 -		list_add_tail(&head->lru, &movable_page_list);
 -		mod_node_page_state(page_pgdat(head),
 -				    NR_ISOLATED_ANON + page_is_file_lru(head),
 -				    thp_nr_pages(head));
++		list_add_tail(&folio->lru, &movable_page_list);
++		node_stat_mod_folio(folio,
++				    NR_ISOLATED_ANON + folio_is_file_lru(folio),
++				    folio_nr_pages(folio));
  	}
  
+ 	if (!list_empty(&movable_page_list) || isolation_error_count)
+ 		goto unpin_pages;
+ 
  	/*
  	 * If list is empty, and no isolation errors, means that all pages are
  	 * in the correct zone.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread
* linux-next: manual merge of the akpm-current tree with the folio tree
@ 2022-02-15  7:00 Stephen Rothwell
  2022-02-15 13:12 ` Matthew Wilcox
  0 siblings, 1 reply; 24+ messages in thread
From: Stephen Rothwell @ 2022-02-15  7:00 UTC (permalink / raw)
  To: Matthew Wilcox, Andrew Morton
  Cc: Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

Hi all,

Today's linux-next merge of the block tree got conflicts in:

  include/linux/mm.h
  include/linux/rmap.h
  mm/gup.c
  mm/huge_memory.c
  mm/internal.h
  mm/memory-failure.c
  mm/migrate.c
  mm/mlock.c
  mm/rmap.c
  mm/vmscan.c

There is no way I can figure out in a reasonable time (or at all
probably) the resolution needed here.  You guys need to get together
and figure out how the folio tree changes are going to progress to
Linus' tree.

I have gone back and used the folio tree from next-20220204 again for
today.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 24+ messages in thread
* linux-next: manual merge of the akpm-current tree with the folio tree
@ 2021-12-10 21:17 broonie
  0 siblings, 0 replies; 24+ messages in thread
From: broonie @ 2021-12-10 21:17 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Alistair Popple, Linux Kernel Mailing List,
	Linux Next Mailing List, Mark Brown, Matthew Wilcox

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/migrate.c

between commit:

  2871d169178ba ("filemap: Add folio_put_wait_locked()")

from the folio tree and commit:

  dfbfdd72f50ce ("mm/migrate.c: rework migration_entry_wait() to not take a pageref")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc mm/migrate.c
index 7079e6b7dbe7d,d487a399253b0..0000000000000
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@@ -302,17 -303,10 +303,9 @@@ void __migration_entry_wait(struct mm_s
  	if (!is_migration_entry(entry))
  		goto out;
  
 -	page = pfn_swap_entry_to_page(entry);
 -	page = compound_head(page);
 +	folio = page_folio(pfn_swap_entry_to_page(entry));
  
- 	/*
- 	 * Once page cache replacement of page migration started, page_count
- 	 * is zero; but we must not call folio_put_wait_locked() without
- 	 * a ref. Use folio_try_get(), and just fault again if it fails.
- 	 */
- 	if (!folio_try_get(folio))
- 		goto out;
- 	pte_unmap_unlock(ptep, ptl);
- 	folio_put_wait_locked(folio, TASK_UNINTERRUPTIBLE);
 -	migration_entry_wait_on_locked(page_folio(page), ptep, ptl);
++	migration_entry_wait_on_locked(folio, ptep, ptl);
  	return;
  out:
  	pte_unmap_unlock(ptep, ptl);

^ permalink raw reply	[flat|nested] 24+ messages in thread
* linux-next: manual merge of the akpm-current tree with the folio tree
@ 2021-07-21  6:02 Stephen Rothwell
  2021-09-06  4:49 ` Stephen Rothwell
  0 siblings, 1 reply; 24+ messages in thread
From: Stephen Rothwell @ 2021-07-21  6:02 UTC (permalink / raw)
  To: Andrew Morton, Matthew Wilcox
  Cc: Jan Kara, Linux Kernel Mailing List, Linux Next Mailing List

[-- Attachment #1: Type: text/plain, Size: 3810 bytes --]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  mm/page-writeback.c

between commits:

  7cfa3de8ce5d ("mm/writeback: Add __folio_end_writeback()")
  e8fc4f61a3e3 ("mm/writeback: Add folio_start_writeback()")

from the folio tree and commit:

  4dd7a4fe8321 ("writeback: track number of inodes under writeback")

from the akpm-current tree.

Willy, thanks for the resolution.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc mm/page-writeback.c
index c2987f05c944,57b98ea365e2..000000000000
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@@ -2751,17 -2739,34 +2763,35 @@@ bool folio_clear_dirty_for_io(struct fo
  		unlocked_inode_to_wb_end(inode, &cookie);
  		return ret;
  	}
 -	return TestClearPageDirty(page);
 +	return folio_test_clear_dirty(folio);
  }
 -EXPORT_SYMBOL(clear_page_dirty_for_io);
 +EXPORT_SYMBOL(folio_clear_dirty_for_io);
  
+ static void wb_inode_writeback_start(struct bdi_writeback *wb)
+ {
+ 	atomic_inc(&wb->writeback_inodes);
+ }
+ 
+ static void wb_inode_writeback_end(struct bdi_writeback *wb)
+ {
+ 	atomic_dec(&wb->writeback_inodes);
+ 	/*
+ 	 * Make sure estimate of writeback throughput gets updated after
+ 	 * writeback completed. We delay the update by BANDWIDTH_INTERVAL
+ 	 * (which is the interval other bandwidth updates use for batching) so
+ 	 * that if multiple inodes end writeback at a similar time, they get
+ 	 * batched into one bandwidth update.
+ 	 */
+ 	queue_delayed_work(bdi_wq, &wb->bw_dwork, BANDWIDTH_INTERVAL);
+ }
+ 
 -int test_clear_page_writeback(struct page *page)
 +bool __folio_end_writeback(struct folio *folio)
  {
 -	struct address_space *mapping = page_mapping(page);
 -	int ret;
 +	long nr = folio_nr_pages(folio);
 +	struct address_space *mapping = folio_mapping(folio);
 +	bool ret;
  
 -	lock_page_memcg(page);
 +	folio_memcg_lock(folio);
  	if (mapping && mapping_use_writeback_tags(mapping)) {
  		struct inode *inode = mapping->host;
  		struct backing_dev_info *bdi = inode_to_bdi(inode);
@@@ -2775,8 -2780,11 +2805,11 @@@
  			if (bdi->capabilities & BDI_CAP_WRITEBACK_ACCT) {
  				struct bdi_writeback *wb = inode_to_wb(inode);
  
 -				dec_wb_stat(wb, WB_WRITEBACK);
 -				__wb_writeout_inc(wb);
 +				wb_stat_mod(wb, WB_WRITEBACK, -nr);
 +				__wb_writeout_add(wb, nr);
+ 				if (!mapping_tagged(mapping,
+ 						    PAGECACHE_TAG_WRITEBACK))
+ 					wb_inode_writeback_end(wb);
  			}
  		}
  
@@@ -2821,14 -2827,18 +2854,18 @@@ bool __folio_start_writeback(struct fol
  						   PAGECACHE_TAG_WRITEBACK);
  
  			xas_set_mark(&xas, PAGECACHE_TAG_WRITEBACK);
- 			if (bdi->capabilities & BDI_CAP_WRITEBACK_ACCT)
- 				wb_stat_mod(inode_to_wb(inode), WB_WRITEBACK,
- 						nr);
+ 			if (bdi->capabilities & BDI_CAP_WRITEBACK_ACCT) {
+ 				struct bdi_writeback *wb = inode_to_wb(inode);
+ 
 -				inc_wb_stat(wb, WB_WRITEBACK);
++				wb_stat_mod(wb, WB_WRITEBACK, nr);
+ 				if (!on_wblist)
+ 					wb_inode_writeback_start(wb);
+ 			}
  
  			/*
 -			 * We can come through here when swapping anonymous
 -			 * pages, so we don't necessarily have an inode to track
 -			 * for sync.
 +			 * We can come through here when swapping
 +			 * anonymous folios, so we don't necessarily
 +			 * have an inode to track for sync.
  			 */
  			if (mapping->host && !on_wblist)
  				sb_mark_inode_writeback(mapping->host);

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

end of thread, other threads:[~2022-04-08  5:18 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-21  6:31 linux-next: manual merge of the akpm-current tree with the folio tree Stephen Rothwell
2021-09-06  4:48 ` Stephen Rothwell
2021-09-06 12:12   ` Matthew Wilcox
2021-09-06 16:56     ` Suren Baghdasaryan
2021-09-06 21:35       ` Stephen Rothwell
2021-09-07 13:49   ` Matthew Wilcox
  -- strict thread matches above, loose matches on Subject: below --
2022-04-08  5:18 Stephen Rothwell
2022-04-08  5:08 Stephen Rothwell
2022-03-22  8:35 Stephen Rothwell
2022-02-16  6:15 Stephen Rothwell
2022-02-15  7:00 Stephen Rothwell
2022-02-15 13:12 ` Matthew Wilcox
2022-02-16  6:21   ` Stephen Rothwell
2022-02-16  9:49     ` Stephen Rothwell
2022-02-16 20:41     ` Matthew Wilcox
2022-02-17  5:30       ` Stephen Rothwell
2022-02-17  5:51         ` Andrew Morton
2022-02-17  6:38           ` Stephen Rothwell
2022-02-17 21:19             ` Matthew Wilcox
2022-02-19  7:27               ` Christoph Hellwig
2022-02-20  0:17               ` Stephen Rothwell
2021-12-10 21:17 broonie
2021-07-21  6:02 Stephen Rothwell
2021-09-06  4:49 ` Stephen Rothwell

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