Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

On 03/08/2018 09:15 AM, Ming Lei wrote: > On Thu, Mar 08, 2018 at 08:50:35AM +0100, Christoph Hellwig wrote: >>> +static void hpsa_setup_reply_map(struct ctlr_info *h) >>> +{ >>> + const struct cpumask *mask; >>> + unsigned int queue, cpu; >>> + >>> + for (queue = 0; queue < h->msix_vectors;

Re: [PATCH] block: bio_check_eod() needs to consider partition

Hi Christoph, On 2018/3/8 下午3:46, Christoph Hellwig wrote: > bio_check_eod() should check partiton size not the whole disk if > bio->bi_partno is non-zero. > I think the check should be done twice if the bio->bi_partno is not zero, one for the partition, and another for the whole disk after

Re: [PATCH V3 4/8] blk-mq: introduce BLK_MQ_F_HOST_TAGS

On Thu, Mar 08, 2018 at 08:52:52AM +0100, Christoph Hellwig wrote: > On Tue, Feb 27, 2018 at 06:07:46PM +0800, Ming Lei wrote: > > This patch can support to partition host-wide tags to multiple hw queues, > > so each hw queue related data structures(tags, hctx) can be accessed in > > NUMA locality

Re: [PATCH v2 04/11] block: Protect queue flag changes with the queue lock

Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham

Re: [PATCH v2 09/11] block: Use blk_queue_flag_*() in drivers instead of queue_flag_*()

Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

On Thu, Mar 08, 2018 at 08:50:35AM +0100, Christoph Hellwig wrote: > > +static void hpsa_setup_reply_map(struct ctlr_info *h) > > +{ > > + const struct cpumask *mask; > > + unsigned int queue, cpu; > > + > > + for (queue = 0; queue < h->msix_vectors; queue++) { > > + mask =

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

On Thu, Mar 08, 2018 at 09:41:16AM +0100, Hannes Reinecke wrote: > On 03/08/2018 09:15 AM, Ming Lei wrote: > > On Thu, Mar 08, 2018 at 08:50:35AM +0100, Christoph Hellwig wrote: > >>> +static void hpsa_setup_reply_map(struct ctlr_info *h) > >>> +{ > >>> + const struct cpumask *mask; > >>> +

RE: [PATCH V3 8/8] scsi: megaraid: improve scsi_mq performance via .host_tagset

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Thursday, March 8, 2018 6:46 AM > To: Kashyap Desai > Cc: Jens Axboe; linux-block@vger.kernel.org; Christoph Hellwig; Mike Snitzer; > linux-s...@vger.kernel.org; Hannes Reinecke; Arun Easi; Omar Sandoval; > Martin K

Re: [PATCH V2 3/5] genirq/affinity: move actual irq vector spread into one helper

On Tue, Mar 06, 2018 at 12:28:32AM +0800, kbuild test robot wrote: > Hi Ming, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on tip/irq/core] > [also build test WARNING on v4.16-rc4 next-20180305] > [if your patch is applied to the wrong git tree, please

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

On Wed, Mar 07, 2018 at 09:11:37AM -0500, Laurence Oberman wrote: > On Tue, 2018-03-06 at 14:24 -0500, Martin K. Petersen wrote: > > Ming, > > > > > Given both Don and Laurence have verified that patch 1 and patch 2 > > > does fix IO hang, could you consider to merge the two first? > > > > Oh,

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Thu, 2018-03-08 at 18:53 +0800, Ming Lei wrote: > Hi, > > This patchset tries to spread among online CPUs as far as possible, so > that we can avoid to allocate too less irq vectors with online CPUs > mapped. > > For example, in a 8cores system, 4 cpu cores(4~7) are offline/non present, > on

[PATCH V3 2/4] genirq/affinity: move actual irq vector spread into one helper

No functional change, just prepare for converting to 2-stage irq vector spread. Cc: Thomas Gleixner Reviewed-by: Christoph Hellwig Signed-off-by: Ming Lei --- kernel/irq/affinity.c | 97 +--

Re: [PATCH V3 8/8] scsi: megaraid: improve scsi_mq performance via .host_tagset

On Thu, Mar 08, 2018 at 03:34:31PM +0530, Kashyap Desai wrote: > > -Original Message- > > From: Ming Lei [mailto:ming@redhat.com] > > Sent: Thursday, March 8, 2018 6:46 AM > > To: Kashyap Desai > > Cc: Jens Axboe; linux-block@vger.kernel.org; Christoph Hellwig; Mike > Snitzer; > >

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Thu, 2018-03-08 at 15:18 +0200, Artem Bityutskiy wrote: > Tested-by: Artem Bityutskiy > Link: https://lkml.kernel.org/r/1519311270.2535.53.ca...@intel.com And for completeness: Linux-Regression-ID: lr#15a115

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Thu, Mar 08, 2018 at 03:18:33PM +0200, Artem Bityutskiy wrote: > On Thu, 2018-03-08 at 18:53 +0800, Ming Lei wrote: > > Hi, > > > > This patchset tries to spread among online CPUs as far as possible, so > > that we can avoid to allocate too less irq vectors with online CPUs > > mapped. > > >

[PATCH V3 4/4] genirq/affinity: irq vector spread among online CPUs as far as possible

84676c1f21 ("genirq/affinity: assign vectors to all possible CPUs") may cause irq vector assigned to all offline CPUs, and this kind of assignment may cause much less irq vectors mapped to online CPUs, and performance may get hurt. For example, in a 8 cores system, 0~3 online, 4~8 offline/not

[PATCH V3 3/4] genirq/affinity: support to do irq vectors spread starting from any vector

Now two parameters(start_vec, affv) are introduced to irq_build_affinity_masks(), then this helper can build the affinity of each irq vector starting from the irq vector of 'start_vec', and handle at most 'affv' vectors. This way is required to do 2-stages irq vectors spread among all possible

[PATCH V3 1/4] genirq/affinity: rename *node_to_possible_cpumask as *node_to_cpumask

The following patches will introduce two stage irq spread for improving irq spread on all possible CPUs. No funtional change. Cc: Thomas Gleixner Reviewed-by: Christoph Hellwig Signed-off-by: Ming Lei --- kernel/irq/affinity.c | 26

Re: [PATCH V3 8/8] scsi: megaraid: improve scsi_mq performance via .host_tagset

On Thu, Mar 08, 2018 at 07:06:25PM +0800, Ming Lei wrote: > On Thu, Mar 08, 2018 at 03:34:31PM +0530, Kashyap Desai wrote: > > > -Original Message- > > > From: Ming Lei [mailto:ming@redhat.com] > > > Sent: Thursday, March 8, 2018 6:46 AM > > > To: Kashyap Desai > > > Cc: Jens Axboe;

Re: [PATCH V3 7/8] scsi: hpsa: improve scsi_mq performance via .host_tagset

On Thu, Mar 08, 2018 at 08:54:43AM +0100, Christoph Hellwig wrote: > > + /* 256 tags should be high enough to saturate device */ > > + int max_queues = DIV_ROUND_UP(h->scsi_host->can_queue, 256); > > + > > + /* per NUMA node hw queue */ > > + h->scsi_host->nr_hw_queues = min_t(int,

Re: [PATCH] block: bio_check_eod() needs to consider partition

On Thu, Mar 08, 2018 at 04:17:19PM +0800, Jiufei Xue wrote: > Hi Christoph, > > On 2018/3/8 下午3:46, Christoph Hellwig wrote: > > bio_check_eod() should check partiton size not the whole disk if > > bio->bi_partno is non-zero. > > > I think the check should be done twice if the bio->bi_partno is

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

On Thu, 2018-03-08 at 21:42 +0800, Ming Lei wrote: > On Wed, Mar 07, 2018 at 09:11:37AM -0500, Laurence Oberman wrote: > > On Tue, 2018-03-06 at 14:24 -0500, Martin K. Petersen wrote: > > > Ming, > > > > > > > Given both Don and Laurence have verified that patch 1 and > > > > patch 2 > > > > does

Re: [PATCH] block: bio_check_eod() needs to consider partition

On Thu, Mar 08 2018, Christoph Hellwig wrote: > bio_check_eod() should check partiton size not the whole disk if > bio->bi_partno is non-zero. > > Based on an earlier patch from Jiufei Xue. This doesn't apply, what did you generate it against? -- Jens Axboe

Re: [PATCH v2 00/11] Make all concurrent queue flag manipulations safe

On Wed, Mar 07 2018, Bart Van Assche wrote: > Hello Jens, > > As you probably know there is considerable confusion in the block > layer core and in block drivers about how to protect queue flag > changes against concurrent modifications. Some code protects these > changes with the queue lock,

[PATCH V4 1/4] scsi: hpsa: fix selection of reply queue

>From 84676c1f21 (genirq/affinity: assign vectors to all possible CPUs), one msix vector can be created without any online CPU mapped, then one command's completion may not be notified. This patch setups mapping between cpu and reply queue according to irq affinity info retrived by

[PATCH V4 0/4] SCSI: fix selection of reply(hw) queue

Hi All, The patches fixes reply queue(virt-queue on virtio-scsi) selection on hpsa, megaraid_sa and virtio-scsi, and IO hang can be caused easily by this issue. This issue is triggered by 84676c1f21e8 ("genirq/affinity: assign vectors to all possible CPUs"). After 84676c1f21e8, it is easy to see

[PATCH V4 3/4] scsi: introduce force_blk_mq

>From scsi driver view, it is a bit troublesome to support both blk-mq and non-blk-mq at the same time, especially when drivers need to support multi hw-queue. This patch introduces 'force_blk_mq' to scsi_host_template so that drivers can provide blk-mq only support, so driver code can avoid the

[PATCH V4 4/4] scsi: virtio_scsi: fix IO hang caused by irq vector automatic affinity

Now 84676c1f21e8ff5(genirq/affinity: assign vectors to all possible CPUs) has been merged to V4.16-rc, and it is easy to allocate all offline CPUs for some irq vectors, this can't be avoided even though the allocation is improved. For example, on a 8cores VM, 4~7 are not-present/offline, 4 queues

Re: [PATCH V4 0/4] SCSI: fix selection of reply(hw) queue

On Fri, Mar 09, 2018 at 08:00:52AM +0100, Hannes Reinecke wrote: > On 03/09/2018 04:32 AM, Ming Lei wrote: > > Hi All, > > > > The patches fixes reply queue(virt-queue on virtio-scsi) selection on hpsa, > > megaraid_sa and virtio-scsi, and IO hang can be caused easily by this issue. > > > > This

Re: [PATCH v2 08/10] nvme-pci: Add support for P2P memory in requests

On Thu, 2018-03-01 at 15:58 +, Stephen Bates wrote: > > Any plans adding the capability to nvme-rdma? Should be > > straight-forward... In theory, the use-case would be rdma backend > > fabric behind. Shouldn't be hard to test either... > > Nice idea Sagi. Yes we have been starting to look

Re: [PATCH V4 0/4] SCSI: fix selection of reply(hw) queue

On 03/09/2018 04:32 AM, Ming Lei wrote: > Hi All, > > The patches fixes reply queue(virt-queue on virtio-scsi) selection on hpsa, > megaraid_sa and virtio-scsi, and IO hang can be caused easily by this issue. > > This issue is triggered by 84676c1f21e8 ("genirq/affinity: assign vectors > to all

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Fri, 2018-03-09 at 09:24 +0800, Ming Lei wrote: > Hi Thomas, > > On Fri, Mar 09, 2018 at 12:20:09AM +0100, Thomas Gleixner wrote: > > On Thu, 8 Mar 2018, Ming Lei wrote: > > > Actually, it isn't a real fix, the real one is in the following > > > two: > > > > > > 0c20244d458e scsi:

RE: [PATCH V3 8/8] scsi: megaraid: improve scsi_mq performance via .host_tagset

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Thursday, March 8, 2018 4:54 PM > To: Kashyap Desai > Cc: Jens Axboe; linux-block@vger.kernel.org; Christoph Hellwig; Mike Snitzer; > linux-s...@vger.kernel.org; Hannes Reinecke; Arun Easi; Omar Sandoval; > Martin K

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Fri, Mar 09, 2018 at 09:00:08AM +0200, Artem Bityutskiy wrote: > On Fri, 2018-03-09 at 09:24 +0800, Ming Lei wrote: > > Hi Thomas, > > > > On Fri, Mar 09, 2018 at 12:20:09AM +0100, Thomas Gleixner wrote: > > > On Thu, 8 Mar 2018, Ming Lei wrote: > > > > Actually, it isn't a real fix, the real

[PATCH] blk-mq-debugfs: Show more request state information

Since commit 634f9e4631a8 ("blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq") blk_rq_is_complete() only reports whether or not a request has completed for legacy queues. Hence modify the blk-mq-debugfs code such that it shows the blk-mq request state again. Fixes: 634f9e4631a8 ("blk-mq:

[PATCH] block: Suppress kernel-doc warnings triggered by blk-zoned.c

Avoid that building with W=1 causes the kernel-doc tool to complain about undocumented function arguments for the blk-zoned.c source file. Signed-off-by: Bart Van Assche Cc: Christoph Hellwig Cc: Damien Le Moal --- block/blk-zoned.c

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Thu, 8 Mar 2018, Ming Lei wrote: > Actually, it isn't a real fix, the real one is in the following two: > > 0c20244d458e scsi: megaraid_sas: fix selection of reply queue > ed6d043be8cd scsi: hpsa: fix selection of reply queue Where are these commits? Neither Linus tree not -next

Re: [PATCH v4] blk-throttle: fix race between blkcg_bio_issue_check() and cgroup_rmdir()

Hello Tejun, Could you please help review this version? Thanks, Joseph On 18/3/6 11:53, Joseph Qi wrote: > We've triggered a WARNING in blk_throtl_bio() when throttling writeback > io, which complains blkg->refcnt is already 0 when calling blkg_get(), > and then kernel crashes with invalid page

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

On Thu, 2018-03-08 at 09:41 +0100, Hannes Reinecke wrote: > IE the _entire_ request set is allocated as _one_ array, making it quite > hard to handle from the lower-level CPU caches. > Also the 'node' indicator doesn't really help us here, as the requests > have to be access by all CPUs in the

Re: [PATCH v7 2/2] Return bytes transferred for partial direct I/O

On 03/07/2018 06:53 PM, Darrick J. Wong wrote: > On Thu, Feb 08, 2018 at 12:59:48PM -0600, Goldwyn Rodrigues wrote: >> From: Goldwyn Rodrigues >> >> In case direct I/O encounters an error midway, it returns the error. >> Instead it should be returning the number of bytes