> + /* 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, nr_node_ids, max_queues);
I don't think this magic should be in a driver. T
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 way, for example, the hw queue can be per NUMA node.
>
> It is observed IO
Looks fine,
Reviewed-by: Christoph Hellwig
> +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 = pci_irq_get_affinity(h->pdev, queue);
> + if (!mask)
> +
Can you fix this up and resend?
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 applie
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.
Fixes: 74d46992e0d9 ("block: replace bi_bdev with a gendisk pointer and
partitions index")
Reported-by: Jiufei Xue
Signed-off-by: Christoph Hellwig
---
block
On Thu, Mar 01, 2018 at 09:23:06AM +0800, Jiufei Xue wrote:
> I think the check should be done twice if the bi_partno is not zero,
> one for the partition, and another for the whole disk after remap which
> is add in the commit 5ddfe9691c91
> ("md: check bio address after mapping through partitions
On Wed, Mar 07, 2018 at 10:58:34PM +0530, Kashyap Desai wrote:
> > >
> > > Also one observation using V3 series patch. I am seeing below Affinity
> > > mapping whereas I have only 72 logical CPUs. It means we are really
> > > not going to use all reply queues.
> > > e.a If I bind fio jobs on CPU 1
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, other code uses atomic operations and some code does not pro
Use blk_queue_flag_set() instead of open-coding this function.
Signed-off-by: Bart Van Assche
Acked-by: Martin K. Petersen
Reviewed-by: Johannes Thumshirn
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Ming Lei
---
drivers/scsi/iscsi_tcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
Move the definition of queue_flag_clear_unlocked() up and move the
definition of queue_in_flight() down such that all queue flag
manipulation function definitions become contiguous.
This patch does not change any functionality.
Signed-off-by: Bart Van Assche
Reviewed-by: Johannes Thumshirn
Revi
This patch has been generated as follows:
for verb in set_unlocked clear_unlocked set clear; do
replace-in-files queue_flag_${verb} blk_queue_flag_${verb%_unlocked} \
$(git grep -lw queue_flag_${verb} drivers block/bsg*)
done
Except for protecting all queue flag changes with the queue lock
This patch helps to avoid that new code gets introduced in block drivers
that manipulates queue flags without holding the queue lock when that
lock should be held.
Signed-off-by: Bart Van Assche
Reviewed-by: Johannes Thumshirn
Reviewed-by: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Re
Introduce functions that modify the queue flags and that protect
these modifications with the request queue lock. Except for moving
one wake_up_all() call from inside to outside a critical section,
this patch does not change any functionality.
Signed-off-by: Bart Van Assche
Reviewed-by: Johannes
Since it is not safe to use queue_flag_(set|clear)_unlocked()
without holding the queue lock after the sysfs entries for a
queue have been created, complain if this happens.
Signed-off-by: Bart Van Assche
Reviewed-by: Johannes Thumshirn
Reviewed-by: Martin K. Petersen
Cc: Mike Snitzer
Cc: Chri
Use the blk_queue_flag_{set,clear}() functions instead of open-coding
these.
Signed-off-by: Bart Van Assche
Reviewed-by: Michael Lyle
Reviewed-by: Johannes Thumshirn
Reviewed-by: Martin K. Petersen
Cc: Kent Overstreet
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Ming Lei
---
drivers/md/b
Use the blk_queue_flag_*() functions instead of open-coding these.
Signed-off-by: Bart Van Assche
Reviewed-by: Johannes Thumshirn
Reviewed-by: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Ming Lei
---
drivers/block/mtip32xx/mtip32xx.c | 8
1 file changed, 4 inse
Except for changing the atomic queue flag manipulations that are
protected by the queue lock into non-atomic manipulations, this
patch does not change any functionality.
Signed-off-by: Bart Van Assche
Reviewed-by: Johannes Thumshirn
Reviewed-by: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Han
Since the queue flags may be changed concurrently from multiple
contexts after a queue becomes visible in sysfs, make these changes
safe by protecting these with the queue lock.
Signed-off-by: Bart Van Assche
Reviewed-by: Martin K. Petersen
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Johanne
Use blk_queue_flag_set() instead of open-coding this function.
Signed-off-by: Bart Van Assche
Reviewed-by: Johannes Thumshirn
Reviewed-by: Martin K. Petersen
Cc: Nicholas A. Bellinger
Cc: Christoph Hellwig
Cc: Hannes Reinecke
Cc: Ming Lei
---
drivers/target/loopback/tcm_loop.c | 2 +-
1 fi
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 transferred so far.
>
> Test case for filesystems (with ENOSPC):
> 1. Create
On Fri, 2018-03-02 at 18:09 -0500, Martin K. Petersen wrote:
> s/manipulaton/manipulation/ in Subject. Otherwise OK.
Will fix that typo. Thanks for the reviewing work!
Bart.
On Wed, Mar 07, 2018 at 04:24:29PM -0700, Scott Bauer wrote:
> On Wed, Mar 07, 2018 at 05:55:56PM +0100, Jonas Rabenstein wrote:
> > The length must be given as bytes and not as 4 bit tuples.
> >
> > Signed-off-by: Jonas Rabenstein
> > ---
> > v2:
> > - use fls64
> > - shorten loop body
> > -
On Wed, Mar 07, 2018 at 05:55:56PM +0100, Jonas Rabenstein wrote:
> The length must be given as bytes and not as 4 bit tuples.
>
> Signed-off-by: Jonas Rabenstein
> ---
> v2:
> - use fls64
> - shorten loop body
> ---
> block/sed-opal.c | 11 ---
> 1 file changed, 4 insertions(+), 7 d
On Tue, Mar 06, 2018 at 04:23:24PM -0800, Derrick, Jonathan wrote:
> This looks correct.
>
> Adding my Ack unless Scott has objections
>
> Acked-by: Jonathan Derrick
Reviewed-by: Scott Bauer
Nice catch Jonas! Sorry you had to resend, my message filtering was a little
too agressive and this s
> >
> > Also one observation using V3 series patch. I am seeing below Affinity
> > mapping whereas I have only 72 logical CPUs. It means we are really
> > not going to use all reply queues.
> > e.a If I bind fio jobs on CPU 18-20, I am seeing only one reply queue
> > is used and that may lead to p
On 03/06/2018 07:23 PM, Chengguang Xu wrote:
> In current code closure debug file is outside of debug directory
> and when unloading module there is lack of removing operation
> for closure debug file, so it will cause creating error when trying
> to reload module.
>
> This patch move closure deb
The length must be given as bytes and not as 4 bit tuples.
Signed-off-by: Jonas Rabenstein
---
v2:
- use fls64
- shorten loop body
---
block/sed-opal.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/block/sed-opal.c b/block/sed-opal.c
index 36842bfa572e..3841
On Wed, Mar 07, 2018 at 08:31:31PM +0530, Kashyap Desai wrote:
> > -Original Message-
> > From: Ming Lei [mailto:ming@redhat.com]
> > Sent: Wednesday, March 7, 2018 10:58 AM
> > To: Kashyap Desai
> > Cc: Jens Axboe; linux-block@vger.kernel.org; Christoph Hellwig; Mike
> Snitzer;
> > lin
> -Original Message-
> From: Ming Lei [mailto:ming@redhat.com]
> Sent: Wednesday, March 7, 2018 10:58 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
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, and I would still need a formal Acked-by: from Don and Tested-by:
> from Laurence.
31 matches
Mail list logo
