On 7/3/25 12:57 AM, Bart Van Assche wrote: > On 7/2/25 3:57 AM, Damien Le Moal wrote: >> On 7/1/25 07:29, Bart Van Assche wrote: >>> diff --git a/block/blk-settings.c b/block/blk-settings.c >>> index a000daafbfb4..bceb9a9cb5ba 100644 >>> --- a/block/blk-settings.c >>> +++ b/block/blk-settings.c >>> @@ -814,6 +814,8 @@ int blk_stack_limits(struct queue_limits *t, struct >>> queue_limits *b, >>> } >>> t->max_secure_erase_sectors = min_not_zero(t->max_secure_erase_sectors, >>> b->max_secure_erase_sectors); >>> + t->driver_preserves_write_order = t->driver_preserves_write_order && >>> + b->driver_preserves_write_order; >> >> Why not use a feature instead ? Stacking of the features does exactly this, no ? >> That would be less code and one less limit. > > Hi Damien, > > Thanks for the feedback. I will look into making this change. > > Please also help with reviewing the other patches in this series. > Progress on this patch series has been slow so far because every time I > post this patch series reviewer feedback is provided on less than 10% of > the code in this patch series. I am still trying to wrap my head around what you are doing with these patches, which is to allocate and submit a BIO from one CPU using the ctx (soft queue) of another CPU, if I understood things correctly (your commit messages are still a little too dry and do not explain a lot, especially the why...). So far, I am not liking what I am seeing because I think it is dangerous given all the per_cpu things around. I do not see how it can be safe to play with one BIO from one CPU to be issued on another. I did suggest that you simply should plug all BIOs, always, and have them submitted by the BIO work for a zone by scheduling that work on a single CPU, always the same CPU. Doing so, you can distribute writes to different zones to different CPUs. And if the submitter process is not bouncing all over the place (being rescheduled constantly on different CPUs), there will be no overhead because you can simply run the BIO work on the current CPU. -- Damien Le Moal Western Digital Research
