linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Andrew Morton <akpm@linux-foundation.org>,
	Matthew Wilcox <willy@infradead.org>
Cc: Jan Kara <jack@suse.cz>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: linux-next: manual merge of the akpm-current tree with the folio tree
Date: Wed, 21 Jul 2021 16:02:28 +1000	[thread overview]
Message-ID: <20210721160228.176a31c9@canb.auug.org.au> (raw)

[-- 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 --]

             reply	other threads:[~2021-07-21  6:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21  6:02 Stephen Rothwell [this message]
2021-09-06  4:49 ` linux-next: manual merge of the akpm-current tree with the folio tree Stephen Rothwell
2021-07-21  6:31 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
2021-12-10 21:17 broonie
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
2022-02-16  6:15 Stephen Rothwell
2022-03-22  8:35 Stephen Rothwell
2022-04-08  5:08 Stephen Rothwell
2022-04-08  5:18 Stephen Rothwell

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=20210721160228.176a31c9@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=willy@infradead.org \
    /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).