Re: [dm-devel] [PATCH 0/6] Overhaul memalloc_no*
On Mon, Jun 29, 2020 at 09:43:23AM -0400, Mikulas Patocka wrote: > On Mon, 29 Jun 2020, Dave Chinner wrote: > > On Sat, Jun 27, 2020 at 09:09:09AM -0400, Mikulas Patocka wrote: > > > On Sat, 27 Jun 2020, Dave Chinner wrote: > > > > On Fri, Jun 26, 2020 at 11:02:19AM -0400, Mikulas Patocka wrote: > > > > > Hi > > > > > > > > > > I suggest to join memalloc_noio and memalloc_nofs into just one flag > > > > > that > > > > > prevents both filesystem recursion and i/o recursion. > > > > > > > > > > Note that any I/O can recurse into a filesystem via the loop device, > > > > > thus > > > > > it doesn't make much sense to have a context where PF_MEMALLOC_NOFS > > > > > is set > > > > > and PF_MEMALLOC_NOIO is not set. > > > > > > > > Correct me if I'm wrong, but I think that will prevent swapping from > > > > GFP_NOFS memory reclaim contexts. > > > > > > Yes. > > > > > > > IOWs, this will substantially > > > > change the behaviour of the memory reclaim system under sustained > > > > GFP_NOFS memory pressure. Sustained GFP_NOFS memory pressure is > > > > quite common, so I really don't think we want to telling memory > > > > reclaim "you can't do IO at all" when all we are trying to do is > > > > prevent recursion back into the same filesystem. > > > > > > So, we can define __GFP_ONLY_SWAP_IO and __GFP_IO. > > > > Uh, why? > > > > Exactly what problem are you trying to solve here? > > This: > > 1. The filesystem does a GFP_NOFS allocation. > 2. The allocation calls directly a dm-bufio shrinker. > 3. The dm-bufio shrinker sees that there is __GFP_IO set, so it assumes >that it can do I/O. It selects some dirty buffers, writes them back and >waits for the I/O to finish. And so you are doing IO in a GFP_NOFS context because someone thought the block layer can't recurse back into filesystems? That's a broken assumption and has been since the loop device was introduced over a couple of decades ago. I mean, the dm-bufio IO submission path uses GFP_NOIO for obvious reasons, but once it's in the next device down it loses all control of the submission context. This is what I mean about "looking at reclaim contexts above the current layer is a Big Red Flag"? The fundamental assumption of dm-bufio that it can issue IO in GFP_NOFS context and not have a lower layer recurse back into a filesystem has always been incorrect. Just because the loop device now does GFP_NOIO allocation, that doesn't mean what dm-bufio is doing in this shrinker is correct or valid. Because, as you point out: > 4. The dirty buffers belong to a loop device. > 5. The loop device thread calls the filesystem that did the GFP_NOFS >allocation in step 1 (and that is still waiting for the allocation to >succeed). > Note that setting PF_MEMALLOC_NOIO on the loop thread won't help with this > deadlock. Right, re-entering the filesystem might block on a lock, IO, memory allocation, journal space reservation, etc. Indeed, it might not even be able to issue transactions because the allocating context is using GFP_NOFS because it is already running a transaction. > Do you argue that this is a bug in dm-bufio? Or a bug in the kernel? Or > that it can't happen? That's a bug in dm-bufio - dm is a layered block device and so has _always_ been able to have filesystems both above and below it in the storage stack. i.e. the assumption that there is no filesystem context under the DM layers has always been wrong. i.e. the memory reclaim context specfically directed dm-bufio that whatever the shrinker does, it must not recurse into the filesystem layer. It is the responsibility of the shrinker to obey the constraints it was given by memory reclaim, and the dm-bufio shrinker's assumption that there cannot be a filesystem below the DM device violates this directive because, quite clearly, there can be filesystems underneath DM devices. IOWs, assuming that you can issue and block on IO from a -layered block device- in GFP_NOFS shrinker context is flawed. i.e. Anything that presents as a block device that is layered on top of another block device can recurse into a filesystem as they can sit on top of a loop device. This has always been the case, and that means the assumptions the dm-bufio shrinker is making about what it can do in GFP_NOFS shrinker context has always been incorrect. Remember that I explained "you should not block kswapd" in this shrinker a year ago? | What follows from that, and is pertinent for in this situation, is | that if you don't block kswapd, then other reclaim contexts are not | going to get stuck waiting for it regardless of the reclaim context | they use. https://lore.kernel.org/linux-fsdevel/20190809215733.gz7...@dread.disaster.area/ If you did that when I suggested it, this problem would be solved. i.e. The only way to fix this problem once adn for all is to stop using the shrinker as a mechanism to issue and wait on IO. If you need background writeback of dirty buffers, do it from a
Re: [dm-devel] [PATCH 0/6] Overhaul memalloc_no*
On Mon, 29 Jun 2020, Dave Chinner wrote: > On Sat, Jun 27, 2020 at 09:09:09AM -0400, Mikulas Patocka wrote: > > > > > > On Sat, 27 Jun 2020, Dave Chinner wrote: > > > > > On Fri, Jun 26, 2020 at 11:02:19AM -0400, Mikulas Patocka wrote: > > > > Hi > > > > > > > > I suggest to join memalloc_noio and memalloc_nofs into just one flag > > > > that > > > > prevents both filesystem recursion and i/o recursion. > > > > > > > > Note that any I/O can recurse into a filesystem via the loop device, > > > > thus > > > > it doesn't make much sense to have a context where PF_MEMALLOC_NOFS is > > > > set > > > > and PF_MEMALLOC_NOIO is not set. > > > > > > Correct me if I'm wrong, but I think that will prevent swapping from > > > GFP_NOFS memory reclaim contexts. > > > > Yes. > > > > > IOWs, this will substantially > > > change the behaviour of the memory reclaim system under sustained > > > GFP_NOFS memory pressure. Sustained GFP_NOFS memory pressure is > > > quite common, so I really don't think we want to telling memory > > > reclaim "you can't do IO at all" when all we are trying to do is > > > prevent recursion back into the same filesystem. > > > > So, we can define __GFP_ONLY_SWAP_IO and __GFP_IO. > > Uh, why? > > Exactly what problem are you trying to solve here? This: 1. The filesystem does a GFP_NOFS allocation. 2. The allocation calls directly a dm-bufio shrinker. 3. The dm-bufio shrinker sees that there is __GFP_IO set, so it assumes that it can do I/O. It selects some dirty buffers, writes them back and waits for the I/O to finish. 4. The dirty buffers belong to a loop device. 5. The loop device thread calls the filesystem that did the GFP_NOFS allocation in step 1 (and that is still waiting for the allocation to succeed). Note that setting PF_MEMALLOC_NOIO on the loop thread won't help with this deadlock. Do you argue that this is a bug in dm-bufio? Or a bug in the kernel? Or that it can't happen? > > I saw this deadlock in the past in the dm-bufio subsystem - see the commit > > 9d28eb12447ee08bb5d1e8bb3195cf20e1ecd1c0 that fixed it. > > 2014? > > /me looks closer. > > Hmmm. Only sent to dm-devel, no comments, no review, just merged. > No surprise that nobody else actually knows about this commit. Well, > time to review it ~6 years after it was merged > > | dm-bufio tested for __GFP_IO. However, dm-bufio can run on a loop block > | device that makes calls into the filesystem. If __GFP_IO is present and > | __GFP_FS isn't, dm-bufio could still block on filesystem operations if it > | runs on a loop block device. > > OK, so from an architectural POV, this commit is fundamentally > broken - block/device layer allocation should not allow relcaim > recursion into filesystems because filesystems are dependent on > the block layer making forwards progress. This commit is trying to > work around the loop device doing GFP_KERNEL/GFP_NOFS context > allocation back end IO path of the loop device. This part of the > loop device is a block device, so needs to run under GFP_NOIO > context. I agree that it is broken, but it fixes the above deadlock. Mikulas -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] [PATCH 0/6] Overhaul memalloc_no*
On Sat 27-06-20 09:08:47, Dave Chinner wrote: > On Fri, Jun 26, 2020 at 11:02:19AM -0400, Mikulas Patocka wrote: > > Hi > > > > I suggest to join memalloc_noio and memalloc_nofs into just one flag that > > prevents both filesystem recursion and i/o recursion. > > > > Note that any I/O can recurse into a filesystem via the loop device, thus > > it doesn't make much sense to have a context where PF_MEMALLOC_NOFS is set > > and PF_MEMALLOC_NOIO is not set. > > Correct me if I'm wrong, but I think that will prevent swapping from > GFP_NOFS memory reclaim contexts. IOWs, this will substantially > change the behaviour of the memory reclaim system under sustained > GFP_NOFS memory pressure. Sustained GFP_NOFS memory pressure is > quite common, so I really don't think we want to telling memory > reclaim "you can't do IO at all" when all we are trying to do is > prevent recursion back into the same filesystem. > > Given that the loop device IO path already operates under > memalloc_noio context, (i.e. the recursion restriction is applied in > only the context that needs is) I see no reason for making that a > global reclaim limitation > > In reality, we need to be moving the other way with GFP_NOFS - to > fine grained anti-recursion contexts, not more broad contexts. Absolutely agreed! It is not really hard to see system struggling due to heavy FS metadata workload while there are objects which could be reclaimed. > That is, GFP_NOFS prevents recursion into any filesystem, not just > the one that we are actively operating on and needing to prevent > recursion back into. We can safely have reclaim do relcaim work on > other filesysetms without fear of recursion deadlocks, but the > memory reclaim infrastructure does not provide that capability.(*) > > e.g. if memalloc_nofs_save() took a reclaim context structure that > the filesystem put the superblock, the superblock's nesting depth > (because layering on loop devices can create cross-filesystem > recursion dependencies), and any other filesyetm private data the > fs wanted to add, we could actually have reclaim only avoid reclaim > from filesytsems where there is a deadlock possiblity. e.g: > > - superblock nesting depth is different, apply GFP_NOFS > reclaim unconditionally > - superblock different apply GFP_KERNEL reclaim > - superblock the same, pass context to filesystem to > decide if reclaim from the sueprblock is safe. > > At this point, we get memory reclaim able to always be able to > reclaim from filesystems that are not at risk of recursion > deadlocks. Direct reclaim is much more likely to be able to make > progress now because it is much less restricted in what it can > reclaim. That's going to make direct relcaim faster and more > efficient, and taht's the ultimate goal we are aiming to acheive > here... Yes, we have discussed something like that few years back at LSFMM IIRC. The scoped NOFS/NOIO api was just a first step to reduce explicit NOFS/NOIO usage with a hope that we will get no-recursion entry points much more well defined and get rid of many instances where "this is a fs code so it has to use NOFS gfp mask". Some of that has happened and that is really great. On the other hand many people still like to use that api as a workaround for an immediate problem because no-recursion scopes are much harder to recognize unless you are supper familiar with the specific fs/IO layer implementation. So this is definitely not a project for somebody to go over all code and just do the clean up. Thanks! -- Michal Hocko SUSE Labs -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] [PATCH 0/6] Overhaul memalloc_no*
On Sat, Jun 27, 2020 at 09:09:09AM -0400, Mikulas Patocka wrote: > > > On Sat, 27 Jun 2020, Dave Chinner wrote: > > > On Fri, Jun 26, 2020 at 11:02:19AM -0400, Mikulas Patocka wrote: > > > Hi > > > > > > I suggest to join memalloc_noio and memalloc_nofs into just one flag that > > > prevents both filesystem recursion and i/o recursion. > > > > > > Note that any I/O can recurse into a filesystem via the loop device, thus > > > it doesn't make much sense to have a context where PF_MEMALLOC_NOFS is > > > set > > > and PF_MEMALLOC_NOIO is not set. > > > > Correct me if I'm wrong, but I think that will prevent swapping from > > GFP_NOFS memory reclaim contexts. > > Yes. > > > IOWs, this will substantially > > change the behaviour of the memory reclaim system under sustained > > GFP_NOFS memory pressure. Sustained GFP_NOFS memory pressure is > > quite common, so I really don't think we want to telling memory > > reclaim "you can't do IO at all" when all we are trying to do is > > prevent recursion back into the same filesystem. > > So, we can define __GFP_ONLY_SWAP_IO and __GFP_IO. Uh, why? Exactly what problem are you trying to solve here? > > Given that the loop device IO path already operates under > > memalloc_noio context, (i.e. the recursion restriction is applied in > > only the context that needs is) I see no reason for making that a > > global reclaim limitation > > I think this is a problem. > > Suppose that a filesystem does GFP_NOFS allocation, the allocation > triggers an IO and waits for it to finish, the loop device driver > redirects the IO to the same filesystem that did the GFP_NOFS allocation. The loop device IO path is under memalloc_noio. By -definition-, allocations in that context cannot recurse back into filesystem level reclaim. So either your aren't explaining the problem you are trying to solve clearly, or you're talking about allocations in the IO path that are broken because they don't use GFP_NOIO correctly... > I saw this deadlock in the past in the dm-bufio subsystem - see the commit > 9d28eb12447ee08bb5d1e8bb3195cf20e1ecd1c0 that fixed it. 2014? /me looks closer. Hmmm. Only sent to dm-devel, no comments, no review, just merged. No surprise that nobody else actually knows about this commit. Well, time to review it ~6 years after it was merged | dm-bufio tested for __GFP_IO. However, dm-bufio can run on a loop block | device that makes calls into the filesystem. If __GFP_IO is present and | __GFP_FS isn't, dm-bufio could still block on filesystem operations if it | runs on a loop block device. OK, so from an architectural POV, this commit is fundamentally broken - block/device layer allocation should not allow relcaim recursion into filesystems because filesystems are dependent on the block layer making forwards progress. This commit is trying to work around the loop device doing GFP_KERNEL/GFP_NOFS context allocation back end IO path of the loop device. This part of the loop device is a block device, so needs to run under GFP_NOIO context. IOWs, this commit just papered over the reclaim context layering violation in the loop device by trying to avoid blocking filesystem IO in the dm-bufio shrinker context just in case it was IO from a loop device that was incorrectly tagged as GFP_KERNEL. So, step forward 5 years to 2019, and this change was made: commit d0a255e795ab976481565f6ac178314b34fbf891 Author: Mikulas Patocka Date: Thu Aug 8 11:17:01 2019 -0400 loop: set PF_MEMALLOC_NOIO for the worker thread A deadlock with this stacktrace was observed. The loop thread does a GFP_KERNEL allocation, it calls into dm-bufio shrinker and the shrinker depends on I/O completion in the dm-bufio subsystem. In order to fix the deadlock (and other similar ones), we set the flag PF_MEMALLOC_NOIO at loop thread entry. PID: 474TASK: 8813e11f4600 CPU: 10 COMMAND: "kswapd0" #0 [8813dedfb938] __schedule at 8173f405 #1 [8813dedfb990] schedule at 8173fa27 #2 [8813dedfb9b0] schedule_timeout at 81742fec #3 [8813dedfba60] io_schedule_timeout at 8173f186 #4 [8813dedfbaa0] bit_wait_io at 8174034f #5 [8813dedfbac0] __wait_on_bit at 8173fec8 #6 [8813dedfbb10] out_of_line_wait_on_bit at 8173ff81 #7 [8813dedfbb90] __make_buffer_clean at a038736f [dm_bufio] #8 [8813dedfbbb0] __try_evict_buffer at a0387bb8 [dm_bufio] #9 [8813dedfbbd0] dm_bufio_shrink_scan at a0387cc3 [dm_bufio] #10 [8813dedfbc40] shrink_slab at 811a87ce #11 [8813dedfbd30] shrink_zone at 811ad778 #12 [8813dedfbdc0] kswapd at 811ae92f #13 [8813dedfbec0] kthread at 810a8428 #14 [8813dedfbf50] ret_from_fork at 81745242 PID: 14127 TASK: 881455749c00 CPU: 11
Re: [dm-devel] [PATCH 0/6] Overhaul memalloc_no*
On Sat, 27 Jun 2020, Dave Chinner wrote: > On Fri, Jun 26, 2020 at 11:02:19AM -0400, Mikulas Patocka wrote: > > Hi > > > > I suggest to join memalloc_noio and memalloc_nofs into just one flag that > > prevents both filesystem recursion and i/o recursion. > > > > Note that any I/O can recurse into a filesystem via the loop device, thus > > it doesn't make much sense to have a context where PF_MEMALLOC_NOFS is set > > and PF_MEMALLOC_NOIO is not set. > > Correct me if I'm wrong, but I think that will prevent swapping from > GFP_NOFS memory reclaim contexts. Yes. > IOWs, this will substantially > change the behaviour of the memory reclaim system under sustained > GFP_NOFS memory pressure. Sustained GFP_NOFS memory pressure is > quite common, so I really don't think we want to telling memory > reclaim "you can't do IO at all" when all we are trying to do is > prevent recursion back into the same filesystem. So, we can define __GFP_ONLY_SWAP_IO and __GFP_IO. > Given that the loop device IO path already operates under > memalloc_noio context, (i.e. the recursion restriction is applied in > only the context that needs is) I see no reason for making that a > global reclaim limitation I think this is a problem. Suppose that a filesystem does GFP_NOFS allocation, the allocation triggers an IO and waits for it to finish, the loop device driver redirects the IO to the same filesystem that did the GFP_NOFS allocation. I saw this deadlock in the past in the dm-bufio subsystem - see the commit 9d28eb12447ee08bb5d1e8bb3195cf20e1ecd1c0 that fixed it. Other subsystems that do IO in GFP_NOFS context may deadlock just like bufio. Mikulas -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] [PATCH 0/6] Overhaul memalloc_no*
On Fri, Jun 26, 2020 at 11:02:19AM -0400, Mikulas Patocka wrote: > Hi > > I suggest to join memalloc_noio and memalloc_nofs into just one flag that > prevents both filesystem recursion and i/o recursion. > > Note that any I/O can recurse into a filesystem via the loop device, thus > it doesn't make much sense to have a context where PF_MEMALLOC_NOFS is set > and PF_MEMALLOC_NOIO is not set. Correct me if I'm wrong, but I think that will prevent swapping from GFP_NOFS memory reclaim contexts. IOWs, this will substantially change the behaviour of the memory reclaim system under sustained GFP_NOFS memory pressure. Sustained GFP_NOFS memory pressure is quite common, so I really don't think we want to telling memory reclaim "you can't do IO at all" when all we are trying to do is prevent recursion back into the same filesystem. Given that the loop device IO path already operates under memalloc_noio context, (i.e. the recursion restriction is applied in only the context that needs is) I see no reason for making that a global reclaim limitation In reality, we need to be moving the other way with GFP_NOFS - to fine grained anti-recursion contexts, not more broad contexts. That is, GFP_NOFS prevents recursion into any filesystem, not just the one that we are actively operating on and needing to prevent recursion back into. We can safely have reclaim do relcaim work on other filesysetms without fear of recursion deadlocks, but the memory reclaim infrastructure does not provide that capability.(*) e.g. if memalloc_nofs_save() took a reclaim context structure that the filesystem put the superblock, the superblock's nesting depth (because layering on loop devices can create cross-filesystem recursion dependencies), and any other filesyetm private data the fs wanted to add, we could actually have reclaim only avoid reclaim from filesytsems where there is a deadlock possiblity. e.g: - superblock nesting depth is different, apply GFP_NOFS reclaim unconditionally - superblock different apply GFP_KERNEL reclaim - superblock the same, pass context to filesystem to decide if reclaim from the sueprblock is safe. At this point, we get memory reclaim able to always be able to reclaim from filesystems that are not at risk of recursion deadlocks. Direct reclaim is much more likely to be able to make progress now because it is much less restricted in what it can reclaim. That's going to make direct relcaim faster and more efficient, and taht's the ultimate goal we are aiming to acheive here... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] [PATCH 0/6] Overhaul memalloc_no*
Hi I suggest to join memalloc_noio and memalloc_nofs into just one flag that prevents both filesystem recursion and i/o recursion. Note that any I/O can recurse into a filesystem via the loop device, thus it doesn't make much sense to have a context where PF_MEMALLOC_NOFS is set and PF_MEMALLOC_NOIO is not set. Mikulas On Thu, 25 Jun 2020, Matthew Wilcox (Oracle) wrote: > I want a memalloc_nowait like we have memalloc_noio and memalloc_nofs > for an upcoming patch series, and Jens also wants it for non-blocking > io_uring. It turns out we already have dm-bufio which could benefit > from memalloc_nowait, so it may as well go into the tree now. > > The biggest problem is that we're basically out of PF_ flags, so we need > to find somewhere else to store the PF_MEMALLOC_NOWAIT flag. It turns > out the PF_ flags are really supposed to be used for flags which are > accessed from other tasks, and the MEMALLOC flags are only going to > be used by this task. So shuffling everything around frees up some PF > flags and generally makes the world a better place. > > Patch series also available from > http://git.infradead.org/users/willy/linux.git/shortlog/refs/heads/memalloc > > Matthew Wilcox (Oracle) (6): > mm: Replace PF_MEMALLOC_NOIO with memalloc_noio > mm: Add become_kswapd and restore_kswapd > xfs: Convert to memalloc_nofs_save > mm: Replace PF_MEMALLOC_NOFS with memalloc_nofs > mm: Replace PF_MEMALLOC_NOIO with memalloc_nocma > mm: Add memalloc_nowait > > drivers/block/loop.c | 3 +- > drivers/md/dm-bufio.c | 30 > drivers/md/dm-zoned-metadata.c | 5 +- > fs/iomap/buffered-io.c | 2 +- > fs/xfs/kmem.c | 2 +- > fs/xfs/libxfs/xfs_btree.c | 14 +++--- > fs/xfs/xfs_aops.c | 4 +- > fs/xfs/xfs_buf.c | 2 +- > fs/xfs/xfs_linux.h | 6 --- > fs/xfs/xfs_trans.c | 14 +++--- > fs/xfs/xfs_trans.h | 2 +- > include/linux/sched.h | 7 +-- > include/linux/sched/mm.h | 84 ++ > kernel/sys.c | 8 ++-- > mm/vmscan.c| 16 +-- > 15 files changed, 105 insertions(+), 94 deletions(-) > > -- > 2.27.0 > -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] [PATCH 0/6] Overhaul memalloc_no*
On Thu, Jun 25, 2020 at 10:36:11PM +0200, Michal Hocko wrote: > On Thu 25-06-20 11:48:32, Darrick J. Wong wrote: > > On Thu, Jun 25, 2020 at 12:31:16PM +0100, Matthew Wilcox (Oracle) wrote: > > > I want a memalloc_nowait like we have memalloc_noio and memalloc_nofs > > > for an upcoming patch series, and Jens also wants it for non-blocking > > > io_uring. It turns out we already have dm-bufio which could benefit > > > from memalloc_nowait, so it may as well go into the tree now. > > > > > > The biggest problem is that we're basically out of PF_ flags, so we need > > > to find somewhere else to store the PF_MEMALLOC_NOWAIT flag. It turns > > > out the PF_ flags are really supposed to be used for flags which are > > > accessed from other tasks, and the MEMALLOC flags are only going to > > > be used by this task. So shuffling everything around frees up some PF > > > flags and generally makes the world a better place. > > > > So, uh, how does this intersect with the patch "xfs: reintroduce > > PF_FSTRANS for transaction reservation recursion protection" that > > re-adds PF_TRANS because uh I guess we lost some subtlety or another at > > some point? > > This is independent, really. It just relocates the NOFS flag. PF_TRANS > is reintroduced for a different reason. When I have replaced the > original PF_TRANS by PF_MEMALLOC_NOFS I didn't realized that xfs doesn't > need only the NOFS semantic but also the transaction tracking so this > cannot be a single bit only. So it has to be added back. But > PF_MEMALLOC_NOFS needs to stay for the scoped NOFS semantic. If XFS needs to track transactions, why doesn't it use current->journal_info like btrfs/ceph/ext4/gfs2/nilfs2/reiserfs? -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] [PATCH 0/6] Overhaul memalloc_no*
On Thu, Jun 25, 2020 at 11:48:32AM -0700, Darrick J. Wong wrote: > On Thu, Jun 25, 2020 at 12:31:16PM +0100, Matthew Wilcox (Oracle) wrote: > > I want a memalloc_nowait like we have memalloc_noio and memalloc_nofs > > for an upcoming patch series, and Jens also wants it for non-blocking > > io_uring. It turns out we already have dm-bufio which could benefit > > from memalloc_nowait, so it may as well go into the tree now. > > > > The biggest problem is that we're basically out of PF_ flags, so we need > > to find somewhere else to store the PF_MEMALLOC_NOWAIT flag. It turns > > out the PF_ flags are really supposed to be used for flags which are > > accessed from other tasks, and the MEMALLOC flags are only going to > > be used by this task. So shuffling everything around frees up some PF > > flags and generally makes the world a better place. > > So, uh, how does this intersect with the patch "xfs: reintroduce > PF_FSTRANS for transaction reservation recursion protection" that > re-adds PF_TRANS because uh I guess we lost some subtlety or another at > some point? I don't know. I read that thread, but I couldn't follow the argument. -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
[dm-devel] [PATCH 0/6] Overhaul memalloc_no*
I want a memalloc_nowait like we have memalloc_noio and memalloc_nofs for an upcoming patch series, and Jens also wants it for non-blocking io_uring. It turns out we already have dm-bufio which could benefit from memalloc_nowait, so it may as well go into the tree now. The biggest problem is that we're basically out of PF_ flags, so we need to find somewhere else to store the PF_MEMALLOC_NOWAIT flag. It turns out the PF_ flags are really supposed to be used for flags which are accessed from other tasks, and the MEMALLOC flags are only going to be used by this task. So shuffling everything around frees up some PF flags and generally makes the world a better place. Patch series also available from http://git.infradead.org/users/willy/linux.git/shortlog/refs/heads/memalloc Matthew Wilcox (Oracle) (6): mm: Replace PF_MEMALLOC_NOIO with memalloc_noio mm: Add become_kswapd and restore_kswapd xfs: Convert to memalloc_nofs_save mm: Replace PF_MEMALLOC_NOFS with memalloc_nofs mm: Replace PF_MEMALLOC_NOIO with memalloc_nocma mm: Add memalloc_nowait drivers/block/loop.c | 3 +- drivers/md/dm-bufio.c | 30 drivers/md/dm-zoned-metadata.c | 5 +- fs/iomap/buffered-io.c | 2 +- fs/xfs/kmem.c | 2 +- fs/xfs/libxfs/xfs_btree.c | 14 +++--- fs/xfs/xfs_aops.c | 4 +- fs/xfs/xfs_buf.c | 2 +- fs/xfs/xfs_linux.h | 6 --- fs/xfs/xfs_trans.c | 14 +++--- fs/xfs/xfs_trans.h | 2 +- include/linux/sched.h | 7 +-- include/linux/sched/mm.h | 84 ++ kernel/sys.c | 8 ++-- mm/vmscan.c| 16 +-- 15 files changed, 105 insertions(+), 94 deletions(-) -- 2.27.0 -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] [PATCH 0/6] Overhaul memalloc_no*
On Thu, Jun 25, 2020 at 12:31:16PM +0100, Matthew Wilcox (Oracle) wrote: > I want a memalloc_nowait like we have memalloc_noio and memalloc_nofs > for an upcoming patch series, and Jens also wants it for non-blocking > io_uring. It turns out we already have dm-bufio which could benefit > from memalloc_nowait, so it may as well go into the tree now. > > The biggest problem is that we're basically out of PF_ flags, so we need > to find somewhere else to store the PF_MEMALLOC_NOWAIT flag. It turns > out the PF_ flags are really supposed to be used for flags which are > accessed from other tasks, and the MEMALLOC flags are only going to > be used by this task. So shuffling everything around frees up some PF > flags and generally makes the world a better place. So, uh, how does this intersect with the patch "xfs: reintroduce PF_FSTRANS for transaction reservation recursion protection" that re-adds PF_TRANS because uh I guess we lost some subtlety or another at some point? I don't have any strong opinion on this series one way or another, but seeing as that patch was generating discussion about how PF_MEMALLOC_NO* is not quite the same as PF_TRANS, I kinda want all these competing PF tweaks and reworks to come together into a single series to review, rather than the four(?) different people submitting conflicting changes. [adding Yafang Shao to cc] --D > Patch series also available from > http://git.infradead.org/users/willy/linux.git/shortlog/refs/heads/memalloc > > Matthew Wilcox (Oracle) (6): > mm: Replace PF_MEMALLOC_NOIO with memalloc_noio > mm: Add become_kswapd and restore_kswapd > xfs: Convert to memalloc_nofs_save > mm: Replace PF_MEMALLOC_NOFS with memalloc_nofs > mm: Replace PF_MEMALLOC_NOIO with memalloc_nocma > mm: Add memalloc_nowait > > drivers/block/loop.c | 3 +- > drivers/md/dm-bufio.c | 30 > drivers/md/dm-zoned-metadata.c | 5 +- > fs/iomap/buffered-io.c | 2 +- > fs/xfs/kmem.c | 2 +- > fs/xfs/libxfs/xfs_btree.c | 14 +++--- > fs/xfs/xfs_aops.c | 4 +- > fs/xfs/xfs_buf.c | 2 +- > fs/xfs/xfs_linux.h | 6 --- > fs/xfs/xfs_trans.c | 14 +++--- > fs/xfs/xfs_trans.h | 2 +- > include/linux/sched.h | 7 +-- > include/linux/sched/mm.h | 84 ++ > kernel/sys.c | 8 ++-- > mm/vmscan.c| 16 +-- > 15 files changed, 105 insertions(+), 94 deletions(-) > > -- > 2.27.0 > -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
Re: [dm-devel] [PATCH 0/6] Overhaul memalloc_no*
On Thu 25-06-20 11:48:32, Darrick J. Wong wrote: > On Thu, Jun 25, 2020 at 12:31:16PM +0100, Matthew Wilcox (Oracle) wrote: > > I want a memalloc_nowait like we have memalloc_noio and memalloc_nofs > > for an upcoming patch series, and Jens also wants it for non-blocking > > io_uring. It turns out we already have dm-bufio which could benefit > > from memalloc_nowait, so it may as well go into the tree now. > > > > The biggest problem is that we're basically out of PF_ flags, so we need > > to find somewhere else to store the PF_MEMALLOC_NOWAIT flag. It turns > > out the PF_ flags are really supposed to be used for flags which are > > accessed from other tasks, and the MEMALLOC flags are only going to > > be used by this task. So shuffling everything around frees up some PF > > flags and generally makes the world a better place. > > So, uh, how does this intersect with the patch "xfs: reintroduce > PF_FSTRANS for transaction reservation recursion protection" that > re-adds PF_TRANS because uh I guess we lost some subtlety or another at > some point? This is independent, really. It just relocates the NOFS flag. PF_TRANS is reintroduced for a different reason. When I have replaced the original PF_TRANS by PF_MEMALLOC_NOFS I didn't realized that xfs doesn't need only the NOFS semantic but also the transaction tracking so this cannot be a single bit only. So it has to be added back. But PF_MEMALLOC_NOFS needs to stay for the scoped NOFS semantic. Hope this clarifies it a bit. -- Michal Hocko SUSE Labs -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
