-rc5-next-20181203+ #1
[2.598170] Hardware name: Google Google Compute Engine/Google
Compute Engine, BIOS Google 01/01/2011
[2.598308] Workqueue: events_unbound async_run_entry_fn
[2.598424] Call Trace:
[2.598549] dump_stack+0x5b/0x8b
[2.598666] print_address_description+0x6a
This is a NEON acceleration method that can improve
performance by approximately 20%. I got the following
data from the centos 7.5 on Huawei's HISI1616 chip:
[ 93.837726] xor: measuring software checksum speed
[ 93.874039] 8regs : 7123.200 MB/sec
[ 93.914038] 32regs : 7180.300 MB/sec
[
In a way similar to ARM commit 09096f6a0ee2 ("ARM: 7822/1: add workaround
for ambiguous C99 stdint.h types"), this patch redefines the macros that
are used in stdint.h so its definitions of uint64_t and int64_t are
compatible with those of the kernel.
This patch comes from:
v6:
neon-intrinsics.h: change _NEON_INTRINSICS_H to __ASM_NEON_INTRINSICS_H.
neon-intrinsics.h: add header LICENSE declaration
neon-intrinsics.h: explain part of the code with comments
Jackie Liu (2):
arm64/neon: add workaround for ambiguous C99 stdint.h types
arm64: crypto: add NEON
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
A driver may wish to iterate every tagged request, not just ones that
satisfy blk_mq_request_started(). The intended use is so a driver may
terminate entered requests on quiesced queues.
How about we just move the started check into the handler passed in for
those that care about it? Much
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
Hi Boris,
On 12/04/2018 12:07 AM, Boris Ostrovsky wrote:
> On 12/2/18 3:31 PM, Manjunath Patil wrote:
>> On 11/30/2018 2:33 PM, Boris Ostrovsky wrote:
>>
>>> On 11/30/18 4:49 PM, Manjunath Patil wrote:
Thank you Boris for your comments. I removed faulty email of mine.
replies
If it really becomes an issue we
should rework the nvme code to also skip the multipath code for any
private namespace, even if that could mean some trouble when rescanning.
This requires some explanation? skip the multipath code how?
Other than that,
Reviewed-by: Sagi Grimberg
Now that we can't poll regular, interrupt driven I/O queues there
is almost nothing that can race with an interrupt. The only
possible other contexts polling a CQ are the error handler and
queue shutdown, and both are so far off in the slow path that
we can simply use the big hammer of
Reviewed-by: Sagi Grimberg
@@ -2428,7 +2426,8 @@ static void nvme_dev_disable(struct nvme_dev *dev, bool
shutdown)
nvme_stop_queues(>ctrl);
if (!dead && dev->ctrl.queue_count > 0) {
- nvme_disable_io_queues(dev);
+ if (nvme_disable_io_queues(dev, nvme_admin_delete_sq))
+
+static int nvme_poll_irqdisable(struct nvme_queue *nvmeq, unsigned int tag)
Do we still need to carry the tag around?
Other than that,
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
Looks good,
Reviewed-by: Sagi Grimberg
@@ -2173,6 +2157,8 @@ static int nvme_setup_io_queues(struct nvme_dev *dev)
if (nr_io_queues == 0)
return 0;
+
+ clear_bit(NVMEQ_ENABLED, >flags);
This is a change of behavior, looks correct though as we can fail
nvme_setup_irqs after we freed the admin
On 12/3/18 5:31 PM, Bart Van Assche wrote:
> On Mon, 2018-12-03 at 15:24 -0700, Jens Axboe wrote:
>> On 12/3/18 3:02 AM, Ming Lei wrote:
>>> Hi,
>>>
>>> Just found there is sbmitmap related lockdep warning, not take a close
>>> look yet, maybe
>>> it is caused by recent sbitmap change.
>>>
>>> [1]
On 12/2/18 8:46 AM, Christoph Hellwig wrote:
Having another indirect all in the fast path doesn't really help
in our post-spectre world. Also having too many queue type is just
going to create confusion, so I'd rather manage them centrally.
Note that the queue type naming and ordering
On Mon, 2018-12-03 at 15:24 -0700, Jens Axboe wrote:
> On 12/3/18 3:02 AM, Ming Lei wrote:
> > Hi,
> >
> > Just found there is sbmitmap related lockdep warning, not take a close
> > look yet, maybe
> > it is caused by recent sbitmap change.
> >
> > [1] test
> > - modprobe null_blk queue_mode=2
On 12/3/18 3:45 PM, Omar Sandoval wrote:
> From: Omar Sandoval
>
> We need to ignore bits in the cleared mask when iterating over all set
> bits.
Thanks Omar, applied.
--
Jens Axboe
From: Omar Sandoval
We need to ignore bits in the cleared mask when iterating over all set
bits.
Fixes: ea86ea2cdced ("sbitmap: ammortize cost of clearing bits")
Signed-off-by: Omar Sandoval
---
include/linux/sbitmap.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff
On 12/3/18 3:02 AM, Ming Lei wrote:
> Hi,
>
> Just found there is sbmitmap related lockdep warning, not take a close
> look yet, maybe
> it is caused by recent sbitmap change.
>
> [1] test
> - modprobe null_blk queue_mode=2 nr_devices=4 shared_tags=1
> submit_queues=1 hw_queue_depth=1
> - then
On 12/3/18 3:05 PM, Omar Sandoval wrote:
> On Mon, Dec 03, 2018 at 02:56:17PM -0700, Jens Axboe wrote:
>> When we are iterating the set bits in a word, we also need to factor in
>> the cleared bits. Don't call fn() unless the bit is also not set in
>> the cleared word.
>>
>> Fixes: ea86ea2cdced
On Mon, Dec 03, 2018 at 02:56:17PM -0700, Jens Axboe wrote:
> When we are iterating the set bits in a word, we also need to factor in
> the cleared bits. Don't call fn() unless the bit is also not set in
> the cleared word.
>
> Fixes: ea86ea2cdced ("sbitmap: ammortize cost of clearing bits")
>
When we are iterating the set bits in a word, we also need to factor in
the cleared bits. Don't call fn() unless the bit is also not set in
the cleared word.
Fixes: ea86ea2cdced ("sbitmap: ammortize cost of clearing bits")
Signed-off-by: Jens Axboe
diff --git a/include/linux/sbitmap.h
On Fri, Nov 30, 2018 at 02:13:54PM -0700, Jens Axboe wrote:
> We only need the request fields and the end_io time if we have
> stats enabled, or if we have a scheduler attached as those may
> use it for completion time stats.
Reviewed-by: Omar Sandoval
> Signed-off-by: Jens Axboe
>
> ---
>
>
On Mon, 3 Dec 2018 at 20:22, Will Deacon wrote:
>
> On Wed, Nov 28, 2018 at 09:09:00AM +0800, Jackie Liu wrote:
> > In a way similar to ARM commit 09096f6a0ee2 ("ARM: 7822/1: add workaround
> > for ambiguous C99 stdint.h types"), this patch redefines the macros that
> > are used in stdint.h so
On Wed, Nov 28, 2018 at 09:09:00AM +0800, Jackie Liu wrote:
> In a way similar to ARM commit 09096f6a0ee2 ("ARM: 7822/1: add workaround
> for ambiguous C99 stdint.h types"), this patch redefines the macros that
> are used in stdint.h so its definitions of uint64_t and int64_t are
> compatible with
On 12/1/2018 10:32 AM, Bart Van Assche wrote:
On 12/1/18 9:11 AM, Hannes Reinecke wrote:
Yes, I'm very much in favour of this, too.
We always have this IMO slightly weird notion of stopping the queue,
set some error flags in the driver, then _restarting_ the queue, just
so that the driver
On Sun, Dec 02, 2018 at 08:46:19AM -0800, Christoph Hellwig wrote:
> This will allow us to simplify both the regular NVMe interrupt handler
> and the upcoming aio poll code. In addition to that the separate
> queues are generally a good idea for performance reasons.
>
> Signed-off-by: Christoph
On Sun, Dec 02, 2018 at 08:46:25AM -0800, Christoph Hellwig wrote:
> The ->poll_fn has been stale for a while, as a lot of places check for mq
> ops. But there is no real point in it anyway, as we don't even use
> the multipath code for subsystems without multiple ports, which is usually
> what
On Sun, Dec 02, 2018 at 08:46:22AM -0800, Christoph Hellwig wrote:
> This is the last place outside of nvme_irq that handles CQEs from
> interrupt context, and thus is in the way of removing the cq_lock for
> normal queues, and avoiding lockdep warnings on the poll queues, for
> which we already
Hi,
Just found there is sbmitmap related lockdep warning, not take a close
look yet, maybe
it is caused by recent sbitmap change.
[1] test
- modprobe null_blk queue_mode=2 nr_devices=4 shared_tags=1
submit_queues=1 hw_queue_depth=1
- then run fio on the 4 null_blk devices
[2] lockdep warning
[
Great! The tests(rocksdb, pblk recovery and the generic xfs suite)
completed successfully on one of our disks, so feel free to add:
Tested-by: Hans Holmberg
Thanks,
Hans
On Fri, Nov 30, 2018 at 2:03 PM Hans Holmberg
wrote:
>
> I just started a regression test on this patch set that'll run over
41 matches
Mail list logo
