Re: [PATCH v4 02/10] block, scsi: Give RQF_PREEMPT back its original meaning
On 08/04/2018 02:03 AM, Bart Van Assche wrote: > In kernel v2.6.18 RQF_PREEMPT was only set for IDE preempt requests. > Later on the SCSI core was modified such that RQF_PREEMPT requests > was set for all requests submitted by __scsi_execute(), including > power management requests. RQF_PREEMPT requests are the only requests > processed in the SDEV_QUIESCE state. Instead of setting RQF_PREEMPT > for all requests submitted by __scsi_execute(), only set RQF_PM for > power management requests. Modify blk_get_request() such that it > blocks in pm-only mode on non-RQF_PM requests. Leave the code out > from scsi_prep_state_check() that is no longer reachable. > > Signed-off-by: Bart Van Assche > Cc: Martin K. Petersen > Cc: Christoph Hellwig > Cc: Jianchao Wang > Cc: Ming Lei > Cc: Alan Stern > Cc: Johannes Thumshirn > --- > block/blk-core.c| 9 + > drivers/scsi/scsi_lib.c | 28 > include/linux/blk-mq.h | 2 ++ > include/linux/blkdev.h | 6 ++ > 4 files changed, 21 insertions(+), 24 deletions(-) > I am not sure this is going to work for SCSI parallel; we're using the QUIESCE state there to do domain validation, and all commands there are most definitely not PM requests. Can you please validate your patches with eg aic7xxx and SCSI parallel disks? Thanks. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
Re: [PATCH v4 01/10] block: Change the preempt-only flag into a counter
On 08/04/2018 02:03 AM, Bart Van Assche wrote: > Rename "preempt-only" into "pm-only" because the primary purpose of > this mode is power management. Since the power management core may > but does not have to resume a runtime suspended device before > performing system-wide suspend and since a later patch will set > "pm-only" mode as long as a block device is runtime suspended, make > it possible to set "pm-only" mode from more than one context. > > Signed-off-by: Bart Van Assche > Cc: Christoph Hellwig > Cc: Jianchao Wang > Cc: Ming Lei > Cc: Johannes Thumshirn > Cc: Alan Stern > --- > block/blk-core.c| 35 ++- > block/blk-mq-debugfs.c | 10 +- > drivers/scsi/scsi_lib.c | 8 > include/linux/blkdev.h | 14 +- > 4 files changed, 40 insertions(+), 27 deletions(-) > Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
Re: [PATCH v4 07/10] block, scsi: Rework runtime power management
Hi Bart On 08/04/2018 08:03 AM, Bart Van Assche wrote: > Instead of allowing requests that are not power management requests > to enter the queue in runtime suspended status (RPM_SUSPENDED), make > the blk_get_request() caller block. Who will resume the runtime suspended device ? In original blk-legacy, when a request is added, blk_pm_add_request will call pm_request_resume could do that. The request will be issued after the q is resumed successfully. After this patch, non-pm request will be blocked and pm_request_resume is removed from blk_pm_add_request, who does resume the runtime suspended q and device ? Thanks Jianchao
Re: [PATCH 0/3] block: fix mismatch of figuring out physical segment number
On Tue, Jul 31, 2018 at 6:49 PM, Ming Lei wrote: > Hi, > > This patchset fixes one issue related with physical segment computation, > which is found by Mike. In case of dm-rq, the warning of > 'blk_cloned_rq_check_limits: > over max segments limit' can be triggered easily. > > Follows the cause: > > 1) in IO fast path(blk_queue_split()), we always figure out physical segment > number > no matter the flag of QUEUE_FLAG_NO_SG_MERGE is set or not. > > 2) only blk_recount_segments() and blk_recalc_rq_segments() uses the flag of > QUEUE_FLAG_NO_SG_MERGE, but the two are only called in some unusual > cases, such as request clone in dm-rq. > > 3) the above two computation don't match, and cause the warning of > "blk_cloned_rq_check_limits: over max segments limit". > > This patchset fixes this issue by killing the queue flag since it is basically > bypassed since v4.4, and no one complains that at all. Also multipage bvec > will > come soon, and it doesn't make sense to keep QUEUE_FLAG_NO_SG_MERGE any more. > > > Ming Lei (3): > block: don't use bio->bi_vcnt to figure out segment number > block: kill QUEUE_FLAG_NO_SG_MERGE > block: kill BLK_MQ_F_SG_MERGE > > block/blk-merge.c| 39 +++ > block/blk-mq-debugfs.c | 2 -- > block/blk-mq.c | 3 --- > drivers/block/loop.c | 2 +- > drivers/block/nbd.c | 2 +- > drivers/block/rbd.c | 2 +- > drivers/block/skd_main.c | 1 - > drivers/block/xen-blkfront.c | 2 +- > drivers/md/dm-rq.c | 2 +- > drivers/md/dm-table.c| 13 - > drivers/mmc/core/queue.c | 3 +-- > drivers/scsi/scsi_lib.c | 2 +- > include/linux/blk-mq.h | 1 - > include/linux/blkdev.h | 1 - > 14 files changed, 14 insertions(+), 61 deletions(-) > > Cc: Christoph Hellwig > Cc: Mike Snitzer > Cc: Kent Overstreet Hello Guys, Ping... Thanks, Ming Lei
Re:bcache-tools repo?
Hi, I'm the maintainer of the bcache-tools package for Fedora, and bcache tools has been quiet for a while so I wasn't paying attention. But I accidentally noticed there's stuff going on again with bcache tools. I did a quick search in the mail archives to see where the new bcache-tools git repository is (I think https://bcache.evilpiepirate.org/ doesn't point in the right direction), and I'm not able to find it. Could anybody point me to the git repo that contains the latest bcache-tools? Thanks! Rolf On 03/15/2018 11:42 AM, Coly Li wrote: Recently I recieve a bug report that bcache does not work on IBM s390x, I find the problem is from endianness support and checksum calculation. Both user space tools and Linux kernel code should be fixed, this patch set is the modification to user space tools. Ideas of this patch set are, 1, super block members should be swapped to little endian before writting down to media. 2, super block members should be explicitly swapped to little endian before calculate checksum. 3, checksum also should be swapped to little endian before writiting down to media. 4, checksum is checked before super block members being swapped into CPU byteorder. The first 3 patches are preparation and the last patch does big endian support. NOTE: Linux kernel code also needs to be patched, this patch set just makes new created bcache devices in a correct byte order. Coly Li --- Coly Li (4): bcache-tools: change bcache.c:crc64() to non-inline function bcache-tools: only set/display sb.bucket_size for cache devices bcache-tools: print more super block information in bcache-super-show bcache-tools: add CPU endianness support bcache-super-show.c | 52 +--- bcache.c| 75 - bcache.h| 19 +--- byteorder.h | 87 + make-bcache.c | 5 +-- 5 files changed, 212 insertions(+), 26 deletions(-) create mode 100644 byteorder.h
Re: nvme updates for 4.19
On 8/5/18 1:33 AM, Christoph Hellwig wrote: > On Sat, Aug 04, 2018 at 12:39:13PM -0600, Jens Axboe wrote: >> On 8/4/18 2:43 AM, Christoph Hellwig wrote: >> This one: >> >>> Christoph Hellwig (9): >>> nvme: add ANA support >> >> Has a stupid conflict with: >> >> commit fa441b71aa27d06fa79d5e7f7c329981dccd94d1 >> Author: Weiping Zhang >> Date: Tue Jul 3 00:34:38 2018 +0800 >> >> nvme: don't enable AEN if not supported >> >> from mainline. Please keep changes like that in mind, that change should >> never have been in the "nvme: add ANA support" patch. > > The addition of the supported bit is because the released version > of the ANA spec was buggy and didn't add the supported bit to the > oaes field. This hasn't been fixed in an erratate and I dropped > the manual addition of the support, but I failed to remove the > local supported variable (which modulo the conflict actually makes > sense, but should indeed not have been part of the commit). Right, the change is fine, it's just fighting a similar change in a different branch. I did fix it up (picked in the original change first), please double check at your convenience. -- Jens Axboe
Re: nvme updates for 4.19
On Sat, Aug 04, 2018 at 12:39:13PM -0600, Jens Axboe wrote: > On 8/4/18 2:43 AM, Christoph Hellwig wrote: > This one: > > > Christoph Hellwig (9): > > nvme: add ANA support > > Has a stupid conflict with: > > commit fa441b71aa27d06fa79d5e7f7c329981dccd94d1 > Author: Weiping Zhang > Date: Tue Jul 3 00:34:38 2018 +0800 > > nvme: don't enable AEN if not supported > > from mainline. Please keep changes like that in mind, that change should > never have been in the "nvme: add ANA support" patch. The addition of the supported bit is because the released version of the ANA spec was buggy and didn't add the supported bit to the oaes field. This hasn't been fixed in an erratate and I dropped the manual addition of the support, but I failed to remove the local supported variable (which modulo the conflict actually makes sense, but should indeed not have been part of the commit).
