Re: [PATCH 1/3] block: make sure discard bio is aligned with logical block size
On Fri, Oct 26, 2018 at 09:44:15AM +0200, Christoph Hellwig wrote: > > if (req_sects > UINT_MAX >> 9) > > - req_sects = UINT_MAX >> 9; > > + req_sects = (UINT_MAX >> 9) & ~bs_mask; > > Given that we have this same thing duplicated in write zeroes > what about a documented helper? IMO, using UINT_MAX & bs_mask is better because it is self-explanatory in the context. If we introduce one helper, it may not be easy to find a better name than UINT_MAX. thanks, Ming
Re: recent issues with heavy delete's causing soft lockups
On Oct 27, 2018, at 12:40 PM, Thomas Fjellstrom wrote: > > Hi > > As of the past few months or so I've been dealing with my workstation locking > up for upwards of minutes at a time when deleting a large directory tree. I > don't recall this being a problem before. > > Current setup is 3 SATA SSDs in an lvm vg. most space is allocated to an ext4 > /home where my work projects live. > > The main use case causing problems is deleting the "out" directory of an > android AOSP build tree. It can be upwards of 95GB in size with 240k or more > files. If I run a `rm -fr out` or `make clean` it will lock up anything > attempting to use the disk (eg: plasma, intellij, android studio, chrome, > etc) > for sometimes minutes. > > I have tried different block scheduler settings including none, mq-deadline, > kyber and bfq none of which seem to improve things much at all. > > It may be worth noting that disk space is starting to run low, perhaps > there's > some interaction going on with free space handling or ssd wear leveling... > > That said, it seems to have started happening (or at least made worse) some > time around when mq was made the default and only implementation for sata. > > if it helps, my system specs are: > > Kernel: Debian Sid's 4.18.0-2-amd64 (4.18.10-2) > CPU: AMD FX-8320 OCed to 4.4Ghz > RAM: 32GB DDR3 1866 > MB: Asus 970 Aura Pro Gaming > Storage: Kingston HyperX 3K 240G + Samsung 850 Evo 250G + SanDisk X300 500G > > I'm thinking of testing with a different or older kernel, what would be the > best to test with? Can you try 4.19? A patch went in since 4.18 that fixes a starvation issue around requeue conditions, which SATA is the one to most often hit. Jens
recent issues with heavy delete's causing soft lockups
Hi As of the past few months or so I've been dealing with my workstation locking up for upwards of minutes at a time when deleting a large directory tree. I don't recall this being a problem before. Current setup is 3 SATA SSDs in an lvm vg. most space is allocated to an ext4 /home where my work projects live. The main use case causing problems is deleting the "out" directory of an android AOSP build tree. It can be upwards of 95GB in size with 240k or more files. If I run a `rm -fr out` or `make clean` it will lock up anything attempting to use the disk (eg: plasma, intellij, android studio, chrome, etc) for sometimes minutes. I have tried different block scheduler settings including none, mq-deadline, kyber and bfq none of which seem to improve things much at all. It may be worth noting that disk space is starting to run low, perhaps there's some interaction going on with free space handling or ssd wear leveling... That said, it seems to have started happening (or at least made worse) some time around when mq was made the default and only implementation for sata. if it helps, my system specs are: Kernel: Debian Sid's 4.18.0-2-amd64 (4.18.10-2) CPU: AMD FX-8320 OCed to 4.4Ghz RAM: 32GB DDR3 1866 MB: Asus 970 Aura Pro Gaming Storage: Kingston HyperX 3K 240G + Samsung 850 Evo 250G + SanDisk X300 500G I'm thinking of testing with a different or older kernel, what would be the best to test with? Thanks for any assistance. -- Thomas Fjellstrom tho...@fjellstrom.ca
Re: [PATCH 01/14] blk-mq: kill q->mq_map
On 10/27/18 10:48 AM, Jens Axboe wrote: > On 10/27/18 8:19 AM, jianchao.wang wrote: >> Hi Jens >> >> On 10/26/18 5:16 AM, Jens Axboe wrote: >>> It's just a pointer to set->mq_map, use that instead. >> Instead of using the set->mq_map and then a two-dimensional set->mq_map, >> how about migrate the mq_map from per-set to per-cpuctx ? >> something like: >> q->queue_hw_ctx[ctx->map[type]] > > I think the current series is pretty clean in that regard, it goes > from members -> map -> map array. I'd be willing to look at a > conversion on top of that, if it makes things cleaner. On top of that, this: q->queue_hw_ctx[set->map[type].mq_map[cpu]] is one less pointer dereference, so more efficient. -- Jens Axboe
Re: [PATCH 01/14] blk-mq: kill q->mq_map
On 10/27/18 8:19 AM, jianchao.wang wrote: > Hi Jens > > On 10/26/18 5:16 AM, Jens Axboe wrote: >> It's just a pointer to set->mq_map, use that instead. > Instead of using the set->mq_map and then a two-dimensional set->mq_map, > how about migrate the mq_map from per-set to per-cpuctx ? > something like: > q->queue_hw_ctx[ctx->map[type]] I think the current series is pretty clean in that regard, it goes from members -> map -> map array. I'd be willing to look at a conversion on top of that, if it makes things cleaner. -- Jens Axboe
Re: [PATCH 01/14] blk-mq: kill q->mq_map
Hi Jens On 10/26/18 5:16 AM, Jens Axboe wrote: > It's just a pointer to set->mq_map, use that instead. Instead of using the set->mq_map and then a two-dimensional set->mq_map, how about migrate the mq_map from per-set to per-cpuctx ? something like: q->queue_hw_ctx[ctx->map[type]] Thanks Jianchao
