simplest fix for this is to make allocations in this path
> non-reclaimable, with GFP_NOIO. With this patch, We couldn't hit the
> issue anymore.
This looks fine.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message
);
> hctx->tags = set->tags[i];
> - WARN_ON(!hctx->tags);
> + BUG_ON(!hctx->tags);
No BUG_ON(), please, it's not necessary to take down the machine if this fails.
It might be game over for that machine, if the driver is hosting the data
or root
ose.
I've added the series, except 6-8, the dm parts. I updated some of the
descriptions/subjects to read a little better.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo
On 11/15/2016 12:11 PM, Omar Sandoval wrote:
From: Omar Sandoval <osan...@fb.com>
Let's not depend on any of the BLK_MQ_RQ_QUEUE_* constants having
specific values. No functional change.
Thanks Omar, applied both for 4.10.
--
Jens Axboe
--
To unsubscribe from this list: send th
ree to apply or not if it's too intrusive.
I think we should clean it up. But you should split this patch in two -
one for NVMe, and one for SCSI.
And it should be against for-4.10/block, the nvme parts don't apply
without fuzz.
--
Jens Axboe
--
To unsubscribe from this list: send the line
E16 commands anyway, make sure that use_16_for_rw is set.
Added to the 4.10 branch, thanks.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ole point of multiple submission queues. Trying to make up some
imaginary 1:1 mapping between submission and completion queues is
nonsensical, when it doesn't exist.
We still should benefit from scsi-mq, though.
Sure, but with 1 submission queue.
--
Jens Axboe
--
To unsubscribe from this list: s
of these sections is a single job. For some reason we are not
merging as well as we should, that's the reason for the performance
loss. In fact, we're not merging at all. That's not IO scheduling.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" i
November 3 at 10
AM such that you can publish these?
I don't think it's related to this thread, but yes, that would be great.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
was exposing lot of non-existing SCSI devices(all SCSI
commands to channels-1,2,3 was
returned as SUCCESS-DID_OK by driver).
Fixes: 1e793f6fc0db920400574211c48f9157a37e3945
Reported-by: Jens Axboe <ax...@kernel.dk>
CC: sta...@vger.kernel.org
Signed-off-by: Kashyap Desai <kashyap.de...@bro
On 11/08/2016 05:20 PM, Kashyap Desai wrote:
-Original Message-
From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
Sent: Wednesday, November 09, 2016 4:45 AM
To: Jens Axboe
Cc: linux-scsi; Kashyap Desai; Martin K. Petersen
Subject: Re: [REGRESSION] 4.9-rc4+ doesn't boot on my
vision: 3.20
[ 10.515186] sr 5:0:0:0: Attached scsi generic sg1 type 5
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
the block tree, but they can go through the SCSI
tree as well. Let me know what folks think.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PCIe MSIx vectors
> Christoph> or use the default.
>
> Jens, any objection to me funneling this change through the SCSI tree?
No, that's fine, you can add my reviewed-by.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body
est
* immediately, even if we have more pending.
*/
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
the Red Hat SRP and NVMe test suites.
This looks pretty good, I'll run some testing on it tomorrow and do a
full review, hopefully we can get it applied sooner rather than later
for the next series.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux
it, I can route this through
libata/for-4.10, or this can be applied to block and libata tree can
pull from it.
I'm fine with that, add my Reviewed-by and funnel it through the libata
tree.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the b
On 10/18/2016 07:53 PM, Martin K. Petersen wrote:
"Jens" == Jens Axboe <ax...@kernel.dk> writes:
Jens> I already queued up the other bits, if it's fine with you I'll add
Jens> 6/7 as well.
Sure. Feel free to add by Acked-by:.
Thanks, added and committed the sd bit. I'
On 10/18/2016 06:46 PM, Martin K. Petersen wrote:
"Jens" == Jens Axboe <ax...@kernel.dk> writes:
Jens> This is starting to look mergeable to me.
Yup.
Jens> Any objections in getting this applied for 4.10? Looks like 6/7
Jens> should go through the SCSI tree, but I ca
Looks like 6/7 should go through the SCSI tree, but I
can queue up the rest.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/13/2016 02:59 PM, Dan Williams wrote:
On Thu, Oct 13, 2016 at 1:24 PM, Jens Axboe <ax...@kernel.dk> wrote:
On 10/13/2016 02:19 PM, Dan Williams wrote:
On Thu, Oct 13, 2016 at 1:09 PM, Jens Axboe <ax...@kernel.dk> wrote:
On 10/13/2016 02:06 PM, Dan Williams wrote:
On
On 10/13/2016 02:19 PM, Dan Williams wrote:
On Thu, Oct 13, 2016 at 1:09 PM, Jens Axboe <ax...@kernel.dk> wrote:
On 10/13/2016 02:06 PM, Dan Williams wrote:
On Thu, Oct 13, 2016 at 12:53 PM, Adam Manzanares
<adam.manzana...@hgst.com> wrote:
Patch adds an association between ioco
to rewrite the commit message though. A good commit
message should explain WHY the change is made, not detail the code
implementation of it.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More m
posing this weird world view on others. We export max_segments and
max_segments_size, which are basically a window into what the DMA engine
can do.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More maj
_sectors (including
sysfs) really want is the lesser of limits.max_hw_sectors and
limits.max_dev_sectors.
It should be the maximum supported to the device, which is the minimum
of any limitations in that path. So I'd say your change is correct.
--
Jens Axboe
--
To unsubscribe from this
On 08/29/2016 12:06 PM, Gabriel Krisman Bertazi wrote:
Jens Axboe <ax...@kernel.dk> writes:
Can you try this patch? It's not perfect, but I'll be interested if it
makes a difference for you.
Hi Jens,
Sorry for the delay. I just got back to this and have been running your
patch
On 08/24/2016 12:34 PM, Jens Axboe wrote:
On 08/23/2016 03:14 PM, Jens Axboe wrote:
On 08/23/2016 03:11 PM, Jens Axboe wrote:
On 08/23/2016 02:54 PM, Gabriel Krisman Bertazi wrote:
Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> writes:
Can you share what you ran to online/offlin
On 08/23/2016 03:14 PM, Jens Axboe wrote:
On 08/23/2016 03:11 PM, Jens Axboe wrote:
On 08/23/2016 02:54 PM, Gabriel Krisman Bertazi wrote:
Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> writes:
Can you share what you ran to online/offline CPUs? I can't reproduce
this her
On 08/23/2016 03:11 PM, Jens Axboe wrote:
On 08/23/2016 02:54 PM, Gabriel Krisman Bertazi wrote:
Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> writes:
Can you share what you ran to online/offline CPUs? I can't reproduce
this here.
I was using the ppc64_cpu tool, which should
loaded. My bash script is different than
yours, I'll try that and see if it helps here.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/19/2016 08:13 AM, Jens Axboe wrote:
On 08/19/2016 07:28 AM, Gabriel Krisman Bertazi wrote:
Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> writes:
We, IBM, have been experiencing eventual Oops when stressing IO at the
same time we add/remove processors. The Oops happens in t
looks like a blk-mq core
bug. Do you have a trace of a BUG() triggering in nvme_queue_rq(), when
req->tag != nvmeq->tags? I don't immediately see how this could happen,
the freezing should protect us from this, unless it's broken somehow.
I'll take a look at this.
--
Jens Axboe
--
To un
rovide a real interface, through a library. Don't expose tons of
zones through sysfs, and expect applications to parse that. That's silly.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More
sysfs. I remember from your presentations that reading
the zone information is slow. Is 10K zones a typical value or a worst
case value?
Just kill the sysfs file, it's useless for many zones. Either have the
application use some library to provide the information, or use bsg and
similar to g
for you and that it just happens to work without.
That's not how you fix problems.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
for improvement in the cpu mapping code.
However, on the original complaint, it's by design (or, working as
intended) - this was done to keep the layout symmetrical. It's been
discussed on the mailing lists before. We can have a discussion whether
we should change this or not, of course.
--
Jens Axboe
a
Fix this by pulling the value at the beginning of the loop.
Signed-off-by: Calvin Owens <calvinow...@fb.com>
Looks good to me.
Reviewed-by: Jens Axboe <ax...@fb.com>
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message
On 02/18/2016 09:40 AM, Tejun Heo wrote:
Hello,
Patchset looks good to me. Once Jens acks the first patch, I'll apply
the whole series to libata/for-4.6 w/ the field initialization
updated.
You can add my acked-by to that one, looks good to me.
--
Jens Axboe
--
To unsubscribe from
ned.
This can be reproduced by issuing SG_IO ioctl()s in one thread while
constantly sending signals to it.
Good catch, fix looks good to me. Applied for 4.5.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a mess
On Feb 9, 2016, at 5:50 AM, Christoph Hellwig <h...@lst.de> wrote:
>
> Jens,
>
> do you want a 'default y' patch or just a better description? I'd be
> happy to send either one.
A better description
--
Jens Axboe
--
To unsubscribe from this list: send the line &q
mount-by-id on those distros.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
rrent series.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
, if the only known
case is suse.
If anything, let's make the description better. It's trying to be funny,
it'd be better if it was descriptive and covered this case as well.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message
stead.
Nick, I've said this before and I'll say this again. Stop sending me
patches. They are all untested and broken, you are wasting peoples time.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.ke
fore that, so I hit this twice today.
Update to the tree as-of yesterday (or today) and it should work.
25364a9e54fb8296 doesn't include the latest block fixes that were sent
in yesterday, that should fix it. You need commit a88d32af18b8 or newer.
--
Jens Axboe
--
To unsubscribe from thi
id=101371
More discussion can be found from below link.
http://marc.info/?l=linux-scsi=144163730531875=2
Added for 4.4, thanks.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majo
K iops is on the slow side, though. It's pointless to iterate the sg
list if we don't have to. I can try and run a few tests next week.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordo
lready, so how is the above
making it any different? In general, NOMERGE being set or not should not
make a difference. It's only a hint that we need not check further if we
should be merging on this request, since we already tried it once, found
we'd exceed various limits, then set NOMERGE
On 11/25/2015 12:10 PM, Hannes Reinecke wrote:
On 11/25/2015 06:56 PM, Jens Axboe wrote:
On 11/25/2015 02:04 AM, Hannes Reinecke wrote:
On 11/20/2015 04:28 PM, Ewan Milne wrote:
On Fri, 2015-11-20 at 15:55 +0100, Hannes Reinecke wrote:
Can't we have a joint effort here?
I've been spending
to manipulate the data.
The only changes in this copy of the code are ones to generalize
function/variable names from md-specific ones. Also add init and free
functions.
Split this into a .c file with the code.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux
On 10/12/2015 02:22 PM, Christoph Hellwig wrote:
On Mon, Oct 12, 2015 at 02:08:04PM -0600, Jens Axboe wrote:
No that's definitely fine with me, imho most error handling callbacks
should be in process context for ease of use in the driver.
Took a closer look. The patch looks incomplete
most error handling callbacks
should be in process context for ease of use in the driver.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On 10/12/2015 01:34 PM, Jens Axboe wrote:
On 10/12/2015 01:29 PM, Christoph Hellwig wrote:
For some pending NVMe work I'd really love to be able to get my timeouts
from process context. So far it seems only SCSI and NVMe use the blk-mq
timeout handler, and both don't seem to be particularly
On 08/17/2015 01:13 PM, Christoph Hellwig wrote:
Does this look fine to you Jens?
I'd love to get this API into 4.3 so I can submit the NFS SCSI layout
patches that depend on it for 4.4.
I'll take a look at this today.
--
Jens Axboe
--
To unsubscribe from this list: send the line
in the host anyway.
Fully agreed. I would vote for making the host template read-only
and modify all drivers to use the shost setting.
Indeed, that would be a much saner choice. The settings in a
(effectively already) read-only host template seems like somewhat of a
relic.
--
Jens Axboe
setting of queue
depth, returning EINVAL for all settings but '1'. And once it's set to
1, there's no way to go back up.
Cc: sta...@kernel.org
Fixes: 1e6f2416044c0 scsi: don't allow setting of queue_depth bigger than
can_queue
Signed-off-by: Jens Axboe ax...@fb.com
---
drivers/scsi/scsi_sysfs.c
it seems to have eliminated
them.
Guys, can someone outside of FB please review this? We're hitting random
memory corruptions without these fixes.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More
On 04/17/2015 03:57 PM, James Bottomley wrote:
On Fri, 2015-04-17 at 15:47 -0600, Jens Axboe wrote:
On 04/17/2015 03:46 PM, James Bottomley wrote:
On Fri, 2015-04-17 at 15:44 -0600, Jens Axboe wrote:
On 04/17/2015 03:42 PM, James Bottomley wrote:
@@ -662,32 +662,14 @@ void
, and this ensures we get better
coverage of over tagging setup over different configs.
Ack! This is great, and makes my life easier...
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info
to be done as two byte stores on some architectures).
It's not in a hot path (by any stretch), so doesn't really matter...
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 04/17/2015 03:46 PM, James Bottomley wrote:
On Fri, 2015-04-17 at 15:44 -0600, Jens Axboe wrote:
On 04/17/2015 03:42 PM, James Bottomley wrote:
@@ -662,32 +662,14 @@ void scsi_finish_command(struct scsi_cmnd *cmd)
*/
int scsi_change_queue_depth(struct scsi_device *sdev, int depth
On 04/17/2015 04:20 PM, James Bottomley wrote:
On Fri, 2015-04-17 at 16:07 -0600, Jens Axboe wrote:
On 04/17/2015 03:57 PM, James Bottomley wrote:
On Fri, 2015-04-17 at 15:47 -0600, Jens Axboe wrote:
On 04/17/2015 03:46 PM, James Bottomley wrote:
On Fri, 2015-04-17 at 15:44 -0600, Jens Axboe
On 04/05/2015 10:03 AM, Christoph Hellwig wrote:
On Fri, Apr 03, 2015 at 09:58:22AM -0600, Jens Axboe wrote:
+struct scsiio_tracker *
+mpt2sas_get_st_from_smid(struct MPT2SAS_ADAPTER *ioc, u16 smid)
+{
+ if (shost_use_blk_mq(ioc-shost)) {
+ struct scsi_cmnd *scmd
IOPS, this effectively
cuts the locking time in half.
Signed-off-by: Jens Axboe ax...@fb.com
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 173 +--
drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 69 +++---
3 files changed
This involves a lot of nasty lookup of a specific running command,
across the host. If anybody is using this code, it should be moved
to proper error handling instead.
Signed-off-by: Jens Axboe ax...@fb.com
---
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 130 +++--
1
IOPS, this effectively
cuts the locking time in half.
Signed-off-by: Jens Axboe ax...@fb.com
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 187 ---
drivers/scsi/mpt2sas/mpt2sas_base.h | 3 +
drivers/scsi/mpt2sas/mpt2sas_scsih.c | 87
3 files changed
, we can't pass in a reliable
request index, since we don't have one...
Signed-off-by: Jens Axboe ax...@fb.com
---
drivers/scsi/scsi.c | 9 +
drivers/scsi/scsi_lib.c | 16
include/scsi/scsi_host.h | 6 +-
3 files changed, 30 insertions(+), 1 deletion(-)
diff
This involves a lot of nasty lookup of a specific running command,
across the host. If anybody is using this code, it should be moved
to proper error handling instead.
Signed-off-by: Jens Axboe ax...@fb.com
---
drivers/scsi/mpt2sas/mpt2sas_ctl.c | 126 +++--
1
For the scsi-mq case, ensure that the request has been started before
returning it from scsi_find_tag(). This is akin to the -special
check for the non-mq case, it ensures that the request has been setup
and issued.
Signed-off-by: Jens Axboe ax...@fb.com
---
include/scsi/scsi_tcq.h | 11
Hi,
This is v2 of the series. Generally addressed Christoph's review comments,
but more specifically, changes since v1:
- Kill the MPI2_FUNCTION_SCSI_TASK_MGMT support, which in turn
enabled me to drop the SCSI/blk iter patches and the smid work-around
for scsi-mq in mpt2/3 for bumping to
On 04/07/2015 10:18 AM, Christoph Hellwig wrote:
On Tue, Apr 07, 2015 at 10:13:23AM -0600, Jens Axboe wrote:
The mq case will also work for the !mq case when you call
scsi_host_find_tag and scsi_cmd_priv. In general all the mq-specific
codepathes you add should become the default and only one
The current iter helper function deals with a hardware queue. Some
callers want to access all queues, like the internal blk-mq timeout
handling does. So add a helper for that.
Signed-off-by: Jens Axboe ax...@fb.com
---
block/blk-mq.c | 35 +++
include
of the search.
Update current callers (blk-mq timeout and NVMe IO cancel).
Signed-off-by: Jens Axboe ax...@fb.com
---
block/blk-mq-tag.c| 6 --
block/blk-mq.c| 10 ++
drivers/block/nvme-core.c | 7 ---
include/linux/blk-mq.h| 2 +-
4 files changed, 15
IOPS, this effectively
cuts the locking time in half.
Signed-off-by: Jens Axboe ax...@fb.com
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 194 +--
drivers/scsi/mpt2sas/mpt2sas_base.h | 3 +
drivers/scsi/mpt2sas/mpt2sas_ctl.c | 119 -
drivers
IOPS, this effectively
cuts the locking time in half.
Signed-off-by: Jens Axboe ax...@fb.com
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 180 +--
drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 119 ++-
drivers
have to store and manage this tracker structure
separately.
In some testing on mpt2sas, this roughly cuts the locking time in half
at just 100K IOPS. Compared to scsi-mq not being enabled, the locking
time with the patchset is reduced from ~47% to just ~4%.
--
Jens Axboe
--
To unsubscribe from
If a LLD has hardware commands in the request pdu, then we need some
helper hooks to help the driver initialize state at load time, and
potentially to tear down state at rmmod time. Add a host template
-init_command() and -exit_command() hook to help with that.
Signed-off-by: Jens Axboe ax
scsi_mq_scmd_to_pdu() returns the LLD pdu associated with a struct
scsi_cmnd.
scsi_mq_scmd_start() returns whether or not a given scsi command
has been started or not.
Signed-off-by: Jens Axboe ax...@fb.com
---
include/scsi/scsi_cmnd.h | 11 +++
1 file changed, 11 insertions(+)
diff
This is basically just a wrapper around blk_mq_queue_busy_iter(),
so that LLDs don't have to deal with or worry about blk-mq hardware
queues.
Signed-off-by: Jens Axboe ax...@fb.com
---
drivers/scsi/scsi_lib.c| 25 +
include/scsi/scsi_device.h | 3 +++
2 files changed
and expose in per-device ro sysfs attr
Applied patch 1 to current tree, marked for stable. 2-4 are applied for
4.1, in for-4.1/core.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info
blk_mq_bitmap
bt-bs = kzalloc(BT_WAIT_QUEUES * sizeof(*bt-bs), GFP_KERNEL);
if (!bt-bs) {
kfree(bt-map);
+ bt-map = NULL;
return -ENOMEM;
}
Thanks Tony, applied.
--
Jens Axboe
--
To unsubscribe from this list: send the line
of it... Does the attached
work?
--
Jens Axboe
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 5f13f4d0bcce..527d315dc1a5 100644
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -88,10 +88,11 @@ int blk_mq_update_queue_map(unsigned int *map, unsigned int nr_queues
, thanks.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/09/2015 04:51 AM, Christoph Hellwig wrote:
Any chance to get a review / ack for this one?
You can my reviewed-by, looks fine to me.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo
the run to a specific workqueue, we'll disable preempt in the current
path before -queue_rq() is called.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On 01/05/2015 12:32 PM, Christoph Hellwig wrote:
On Mon, Jan 05, 2015 at 12:00:58PM -0700, Jens Axboe wrote:
That's not quite true, the only guarantee is that it WILL execute on the
CPU (or CPUs) that are set in the mask. So unless it ends up offloading
the run to a specific workqueue, we'll
. Please resend (dropping
paride), and add proper subject and commit message. Patches 2-4 have
identical subjects, and no commit message...
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 11/25/2014 09:32 AM, Christoph Hellwig wrote:
On Tue, Nov 25, 2014 at 09:30:19AM -0700, Jens Axboe wrote:
On 11/25/2014 09:26 AM, Christoph Hellwig wrote:
This looks reasonable to me. Jens, do you want to takes this
through the block tree?
Acked-by: Christoph Hellwig h...@lst.de
Yeah I
On 11/24/2014 01:27 AM, Christoph Hellwig wrote:
Don't duplicate the code to handle the not cpu bounce case in the
caller, do it inside blk_mq_hctx_next_cpu instead.
Thanks, applied.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message
. And perhaps we can't just modify num_possible_cpus(), we'd need
num_*_cpus() for the other bitmaps, too. That might be breaking other
things...
Meelis, can you try the attached?
--
Jens Axboe
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 1065d7c65fa1..15da9cc08f64 100644
On 11/24/2014 09:22 AM, Paul E. McKenney wrote:
On Mon, Nov 24, 2014 at 08:35:46AM -0700, Jens Axboe wrote:
On 11/24/2014 01:21 AM, Christoph Hellwig wrote:
On Fri, Nov 21, 2014 at 02:56:00PM -0500, David Miller wrote:
I would suggest looking into the possibility that we allocate the memory
On 11/24/2014 10:31 AM, Paul E. McKenney wrote:
On Mon, Nov 24, 2014 at 10:16:15AM -0700, Jens Axboe wrote:
On 11/24/2014 09:22 AM, Paul E. McKenney wrote:
On Mon, Nov 24, 2014 at 08:35:46AM -0700, Jens Axboe wrote:
On 11/24/2014 01:21 AM, Christoph Hellwig wrote:
On Fri, Nov 21, 2014 at 02
On 11/24/2014 02:56 PM, David Miller wrote:
From: Jens Axboe ax...@kernel.dk
Date: Mon, 24 Nov 2014 10:16:15 -0700
How about this one?
The num in num_possible_cpus() means a count, as in how many are
there.
It doesn't mean largest ID of members of set X, which is what you
are asking
On 11/24/2014 03:09 PM, David Miller wrote:
From: Jens Axboe ax...@kernel.dk
Date: Mon, 24 Nov 2014 15:01:55 -0700
I'll just updated blk-mq to use nr_cpu_ids and be done with it.
Wow, a grep on nr_cpu_ids gets a lot of hits on people allocating just
these kinds of tables :)
Yep! It'd
verify that the map that is being used above
has indeed been setup. Unless Christoph has any ideas on what is going
on here?
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
probably be better to shove this debug stuff into the map building
code instead, ala attached.
--
Jens Axboe
diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c
index 1065d7c65fa1..9200e2aee746 100644
--- a/block/blk-mq-cpumap.c
+++ b/block/blk-mq-cpumap.c
@@ -81,6 +81,9 @@ int
this looks like this might be the issue. On a scsi-mq disabled boot,
you have 4 CPUs, but how are they numbered?
We might need Christophs debug patch on top this to fully know...
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord
, nice cleanup and the diffstat is excellent :-)
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
, good catch. Might be an idea to have blk_put_request() do
warn-and-return check on error pointers being passed in, just in case.
--
Jens Axboe
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
is the largest
Chris conceivable reasonable value).
The problem is that finding that is not easy and it too will be a moving
target.
Didn't check, but assuming the value is the upper 24 bits of 32. If so,
might not hurt to check for as 0xfe00 as an invalid value.
--
Jens Axboe
--
To unsubscribe from
201 - 300 of 692 matches
Mail list logo
