| Message ID | YPTu+xHa+0Qz0cOu@casper.infradead.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Folio tree for next | expand |
On Mon, 19 Jul 2021 04:18:19 +0100 Matthew Wilcox <willy@infradead.org> wrote: > Please include a new tree in linux-next: > > https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/for-next > aka > git://git.infradead.org/users/willy/pagecache.git for-next > > There are some minor conflicts with mmotm. I resolved some of them by > pulling in three patches from mmotm and rebasing on top of them. > These conflicts (or near-misses) still remain, and I'm showing my > resolution: I'm thinking that it would be better if I were to base all of the -mm MM patches on linux-next. Otherwise Stephen is going to have a pretty miserable two months...
Hi Andrew, On Sun, 18 Jul 2021 20:57:58 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > > On Mon, 19 Jul 2021 04:18:19 +0100 Matthew Wilcox <willy@infradead.org> wrote: > > > Please include a new tree in linux-next: > > > > https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/for-next > > aka > > git://git.infradead.org/users/willy/pagecache.git for-next > > > > There are some minor conflicts with mmotm. I resolved some of them by > > pulling in three patches from mmotm and rebasing on top of them. > > These conflicts (or near-misses) still remain, and I'm showing my > > resolution: > > I'm thinking that it would be better if I were to base all of the -mm > MM patches on linux-next. Otherwise Stephen is going to have a pretty > miserable two months... If they are only minor conflicts, then please leave them to me (and Linus). That way if Linus decides not to take the folio tree or the mmotm changes (or they get radically changed), then they are not contaminated by each other ... hints (or example resolutions) are always welcome.
Hi Andrew, On Tue, 20 Jul 2021 09:40:33 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Sun, 18 Jul 2021 20:57:58 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > > > > On Mon, 19 Jul 2021 04:18:19 +0100 Matthew Wilcox <willy@infradead.org> wrote: > > > > > Please include a new tree in linux-next: > > > > > > https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/for-next > > > aka > > > git://git.infradead.org/users/willy/pagecache.git for-next > > > > > > There are some minor conflicts with mmotm. I resolved some of them by > > > pulling in three patches from mmotm and rebasing on top of them. > > > These conflicts (or near-misses) still remain, and I'm showing my > > > resolution: > > > > I'm thinking that it would be better if I were to base all of the -mm > > MM patches on linux-next. Otherwise Stephen is going to have a pretty > > miserable two months... > > If they are only minor conflicts, then please leave them to me (and > Linus). That way if Linus decides not to take the folio tree or the > mmotm changes (or they get radically changed), then they are not > contaminated by each other ... hints (or example resolutions) are > always welcome. Also, I prefer to have less, not more, of the mmotm patch set depending on the rest of linux-next since fixing conflicts while rebasing is often more pain than while merging.
On Tue, Jul 20, 2021 at 09:40:33AM +1000, Stephen Rothwell wrote: > Hi Andrew, > > On Sun, 18 Jul 2021 20:57:58 -0700 Andrew Morton <akpm@linux-foundation.org> wrote: > > > > On Mon, 19 Jul 2021 04:18:19 +0100 Matthew Wilcox <willy@infradead.org> wrote: > > > > > Please include a new tree in linux-next: > > > > > > https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/for-next > > > aka > > > git://git.infradead.org/users/willy/pagecache.git for-next > > > > > > There are some minor conflicts with mmotm. I resolved some of them by > > > pulling in three patches from mmotm and rebasing on top of them. > > > These conflicts (or near-misses) still remain, and I'm showing my > > > resolution: > > > > I'm thinking that it would be better if I were to base all of the -mm > > MM patches on linux-next. Otherwise Stephen is going to have a pretty > > miserable two months... > > If they are only minor conflicts, then please leave them to me (and > Linus). That way if Linus decides not to take the folio tree or the > mmotm changes (or they get radically changed), then they are not > contaminated by each other ... hints (or example resolutions) are > always welcome. I think conceptually, the folio for-next tree is part of mmotm for this cycle. I would have asked Andrew to carry these patches, but there are people (eg Dave Howells) who want to develop against them. And that's hard to do with patches that are in mmotm. So if Andrew bases mmotm on the folio tree for this cycle, does that make sense?
Hi Matthew, On Tue, 20 Jul 2021 03:55:44 +0100 Matthew Wilcox <willy@infradead.org> wrote: > > I think conceptually, the folio for-next tree is part of mmotm for this > cycle. I would have asked Andrew to carry these patches, but there are > people (eg Dave Howells) who want to develop against them. And that's > hard to do with patches that are in mmotm. > > So if Andrew bases mmotm on the folio tree for this cycle, does that > make sense? Sure. I will have a little pain the first day it appears, but it should be OK after that. I am on leave starting Saturday, so if you could get me a tree without the mmotm patches for tomorrow that would be good.
On Wed, 21 Jul 2021 12:21:02 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi Matthew, > > On Tue, 20 Jul 2021 03:55:44 +0100 Matthew Wilcox <willy@infradead.org> wrote: > > > > I think conceptually, the folio for-next tree is part of mmotm for this > > cycle. I would have asked Andrew to carry these patches, but there are > > people (eg Dave Howells) who want to develop against them. And that's > > hard to do with patches that are in mmotm. > > > > So if Andrew bases mmotm on the folio tree for this cycle, does that > > make sense? > > Sure. I will have a little pain the first day it appears, but it > should be OK after that. I am on leave starting Saturday, so if you > could get me a tree without the mmotm patches for tomorrow that would > be good. Sure, let's go that way. Linus wasn't terribly enthusiastic about the folio patches and I can't claim to be overwhelmed by their value/churn ratio (but many MM developers are OK with it all, and that counts). Doing it this way retains options...
On Tue, Jul 20, 2021 at 07:29:27PM -0700, Andrew Morton wrote: > On Wed, 21 Jul 2021 12:21:02 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > Hi Matthew, > > > > On Tue, 20 Jul 2021 03:55:44 +0100 Matthew Wilcox <willy@infradead.org> wrote: > > > > > > I think conceptually, the folio for-next tree is part of mmotm for this > > > cycle. I would have asked Andrew to carry these patches, but there are > > > people (eg Dave Howells) who want to develop against them. And that's > > > hard to do with patches that are in mmotm. > > > > > > So if Andrew bases mmotm on the folio tree for this cycle, does that > > > make sense? > > > > Sure. I will have a little pain the first day it appears, but it > > should be OK after that. I am on leave starting Saturday, so if you > > could get me a tree without the mmotm patches for tomorrow that would > > be good. > > Sure, let's go that way. Linus wasn't terribly enthusiastic about the > folio patches and I can't claim to be overwhelmed by their value/churn > ratio (but many MM developers are OK with it all, and that > counts). Doing it this way retains options... I'm happy to take these three patches through my tree if it makes life easier (and it does resolve the majority of the pain): mm, memcg: add mem_cgroup_disabled checks in vmpressure and swap-related functions mm, memcg: inline mem_cgroup_{charge/uncharge} to improve disabled memcg config mm, memcg: inline swap-related functions to improve disabled memcg config Up to you, really.
On Wed, 21 Jul 2021 03:46:52 +0100 Matthew Wilcox <willy@infradead.org> wrote: > > Sure, let's go that way. Linus wasn't terribly enthusiastic about the > > folio patches and I can't claim to be overwhelmed by their value/churn > > ratio (but many MM developers are OK with it all, and that > > counts). Doing it this way retains options... > > I'm happy to take these three patches through my tree if it makes life > easier (and it does resolve the majority of the pain): > > mm, memcg: add mem_cgroup_disabled checks in vmpressure and swap-related functions > mm, memcg: inline mem_cgroup_{charge/uncharge} to improve disabled memcg config > mm, memcg: inline swap-related functions to improve disabled memcg config They're rather unimportant, can be deferred. I'll probably move these to the post-linux-next queue, but let's just do it and see how it goes.
On Tue, Jul 20, 2021 at 08:22:02PM -0700, Andrew Morton wrote: > On Wed, 21 Jul 2021 03:46:52 +0100 Matthew Wilcox <willy@infradead.org> wrote: > > > > Sure, let's go that way. Linus wasn't terribly enthusiastic about the > > > folio patches and I can't claim to be overwhelmed by their value/churn > > > ratio (but many MM developers are OK with it all, and that > > > counts). Doing it this way retains options... > > > > I'm happy to take these three patches through my tree if it makes life > > easier (and it does resolve the majority of the pain): > > > > mm, memcg: add mem_cgroup_disabled checks in vmpressure and swap-related functions > > mm, memcg: inline mem_cgroup_{charge/uncharge} to improve disabled memcg config > > mm, memcg: inline swap-related functions to improve disabled memcg config > > They're rather unimportant, can be deferred. > > I'll probably move these to the post-linux-next queue, but let's just > do it and see how it goes. OK, dropping them from my tree.
Hi Matthew, On Mon, 19 Jul 2021 04:18:19 +0100 Matthew Wilcox <willy@infradead.org> wrote: > > Please include a new tree in linux-next: > > https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/for-next > aka > git://git.infradead.org/users/willy/pagecache.git for-next Added from today. Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgement of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary.
diff --cc mm/page-writeback.c index 57b98ea365e2,c2987f05c944..96b69365de65 --- a/mm/page-writeback.c
Hi Stephen, Please include a new tree in linux-next: https://git.infradead.org/users/willy/pagecache.git/shortlog/refs/heads/for-next aka git://git.infradead.org/users/willy/pagecache.git for-next There are some minor conflicts with mmotm. I resolved some of them by pulling in three patches from mmotm and rebasing on top of them. These conflicts (or near-misses) still remain, and I'm showing my resolution: +++ b/arch/arm/include/asm/cacheflush.h @@@ -290,8 -290,8 +290,9 @@@ extern void flush_cache_page(struct vm_ */ #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1 extern void flush_dcache_page(struct page *); + void flush_dcache_folio(struct folio *folio); +#define ARCH_IMPLEMENTS_FLUSH_KERNEL_VMAP_RANGE 1 static inline void flush_kernel_vmap_range(void *addr, int size) { if ((cache_is_vivt() || cache_is_vipt_aliasing())) +++ b/mm/filemap.c @@@ -836,9 -833,9 +838,9 @@@ void replace_page_cache_page(struct pag new->mapping = mapping; new->index = offset; - mem_cgroup_migrate(old, new); + mem_cgroup_migrate(fold, fnew); - xas_lock_irqsave(&xas, flags); + xas_lock_irq(&xas); xas_store(&xas, new); old->mapping = NULL; +++ b/mm/page-writeback.c @@@ -2739,34 -2751,17 +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); @@@ -2780,11 -2775,8 +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); } } @@@ -2827,18 -2821,14 +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);