From: Hongyu Jin
Since dm-crypt queues writes to a different kernel thread (workqueue),
the bios will dispatch from tasks with different io_context->ioprio
settings and blkcg than the submitting task, thus giving incorrect
ioprio to the io scheduler.
Get the original io priority setting via
From: Hongyu Jin
After obtaining the data, verification or error correction process may
trigger a new I/O that loses the priority of the original I/O, that is,
the verification of the higher priority IO may be blocked by the lower
priority IO.
Make the I/O of verification and error correction
From: Hongyu Jin
Some I/O will dispatch from kworker with different io_context settings
than the submitting task, we may need to specify a priority to avoid
losing priority.
Add I/O priority parameter for dm_bufio_read() and
dm_bufio_prefetch().
Co-developed-by: Yibin Ding
Signed-off-by:
From: Hongyu Jin
Some I/O will dispatch from kworker with different io_context settings
than the submitting task, we may need to specify a priority to avoid
losing priority.
Add I/O priority parameter for dm_io().
Co-developed-by: Yibin Ding
Signed-off-by: Yibin Ding
Signed-off-by: Hongyu
From: Hongyu Jin
Move bio_set_ioprio() into submit_bio():
1. Only call bio_set_ioprio() once to set the priority of original bio,
the bio that cloned and splited from original bio will auto inherit
the priority of original bio in clone process.
2. The IO priority can be passed to module
From: Hongyu Jin
High-priority tasks get data from dm-verity devices via RT IO priority,
I/O will lose RT priority when reading FEC and hash values via kworker
submission IO during verification, and the verification phase may be
blocked by low-priority IO.
Dm-crypt has the same problem in the
Hi,
在 2024/01/24 10:58, Xiao Ni 写道:
Hi all
MD_RECOVERY_WAIT was introduced in d5d885fd5. From this patch,
MD_RECOVERY_WAIT only has one usage during creating raid device.
resync job needs to wait until pers->start finishes(The only place
which is checked). If we remove it from md_do_sync, will
Hi all
MD_RECOVERY_WAIT was introduced in d5d885fd5. From this patch,
MD_RECOVERY_WAIT only has one usage during creating raid device.
resync job needs to wait until pers->start finishes(The only place
which is checked). If we remove it from md_do_sync, will it break the
logic? Or we don't need
When a path is lost and then reinstated later, the ALUA
device handler will not pick up this change and continue
to possibly provide incorrect (stale) information about
its ALUA state to the 'sysfs' prioritizer if the path's
priorities were changed prior to the loss of those paths.
On the loss of
On 1/24/24 08:21, Dave Chinner wrote:
> On Tue, Jan 23, 2024 at 09:39:02PM +0100, Mikulas Patocka wrote:
>>
>>
>> On Tue, 23 Jan 2024, Johannes Thumshirn wrote:
>>
>>> Pass GFP_KERNEL instead of GFP_NOFS to the blkdev_zone_mgmt() call in
>>> zonefs_zone_mgmt().
>>>
>>> As as zonefs_zone_mgmt() and
On Tue, Jan 23, 2024 at 09:39:02PM +0100, Mikulas Patocka wrote:
>
>
> On Tue, 23 Jan 2024, Johannes Thumshirn wrote:
>
> > Pass GFP_KERNEL instead of GFP_NOFS to the blkdev_zone_mgmt() call in
> > zonefs_zone_mgmt().
> >
> > As as zonefs_zone_mgmt() and zonefs_inode_zone_mgmt() are never
On Tue, 23 Jan 2024, Johannes Thumshirn wrote:
> Pass GFP_KERNEL instead of GFP_NOFS to the blkdev_zone_mgmt() call in
> zonefs_zone_mgmt().
>
> As as zonefs_zone_mgmt() and zonefs_inode_zone_mgmt() are never called
> from a place that can recurse back into the filesystem on memory reclaim,
>
On Tue, 23 Jan 2024, Johannes Thumshirn wrote:
> The call to blkdev_zone_mgmt() in dm-zoned is only used to perform a
> ZONE_RESET operation when freeing a zone.
>
> This is not done in the IO path, so we can use GFP_KERNEL here, as it will
> never recurse back into the driver on reclaim.
Hi
Now that all callers pass in GFP_KERNEL to blkdev_zone_mgmt() and use
memalloc_no{io,fs}_{save,restore}() to define the allocation scope, we can
drop the gfp_mask parameter from blkdev_zone_mgmt() as well as
blkdev_zone_reset_all() and blkdev_zone_reset_all_emulated().
Signed-off-by: Johannes
Guard the calls to blkdev_zone_mgmt() with a memalloc_nofs scope.
This helps us getting rid of the GFP_NOFS argument to blkdev_zone_mgmt();
Signed-off-by: Johannes Thumshirn
---
fs/f2fs/segment.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git
Add a memalloc_nofs scope around all calls to blkdev_zone_mgmt(). This
allows us to further get rid of the GFP_NOFS argument for
blkdev_zone_mgmt().
Signed-off-by: Johannes Thumshirn
---
fs/btrfs/zoned.c | 33 ++---
1 file changed, 26 insertions(+), 7 deletions(-)
The call to blkdev_zone_mgmt() in dm-zoned is only used to perform a
ZONE_RESET operation when freeing a zone.
This is not done in the IO path, so we can use GFP_KERNEL here, as it will
never recurse back into the driver on reclaim.
Signed-off-by: Johannes Thumshirn
---
Pass GFP_KERNEL instead of GFP_NOFS to the blkdev_zone_mgmt() call in
zonefs_zone_mgmt().
As as zonefs_zone_mgmt() and zonefs_inode_zone_mgmt() are never called
from a place that can recurse back into the filesystem on memory reclaim,
it is save to call blkdev_zone_mgmt() with GFP_KERNEL.
Fueled by the LSFMM discussion on removing GFP_NOFS initiated by Willy,
I've looked into the sole GFP_NOFS allocation in zonefs. As it turned out,
it is only done for zone management commands and can be removed.
After digging into more callers of blkdev_zone_mgmt() I came to the
conclusion that
19 matches
Mail list logo
