In current pblk implementation, l2p mapping for not closed lines
is always stored only in OOB metadata and recovered from it.
Such a solution does not provide data integrity when drives does
not have such a OOB metadata space.
The goal of this patch is to add support for so called packed
Currently pblk and lightnvm does only check for size
of OOB metadata and does not care wheather this meta
is located in separate buffer or is interleaved with
data in single buffer.
In reality only the first scenario is supported, where
second mode will break pblk functionality during any
IO
Currently whole lightnvm and pblk uses single DMA pool,
for which entry size is always equal to PAGE_SIZE.
PPA list always needs 8B*64, so there is only 56B*64
space for OOB meta. Since NVMe OOB meta can be bigger,
such as 128B, this solution is not robustness.
This patch add the possiblity to
Currently DMA allocated memory is reused on partial read
for lba_list_mem and lba_list_media arrays. In preparation
for dynamic DMA pool sizes we need to move this arrays
into pblk_pr_ctx structures.
Reviewed-by: Javier González
Signed-off-by: Igor Konopko
---
drivers/lightnvm/pblk-read.c | 20
This series of patches extends the way how pblk can
store L2P sector metadata. After this set of changes
any size of NVMe metadata is supported in pblk.
Also there is an support for case without NVMe metadata.
Changes v3 --> v4:
-rename nvm_alloc_dma_pool() to nvm_create_dma_pool()
-split
Currently pblk assumes that size of OOB metadata on drive is always
equal to size of pblk_sec_meta struct. This commit add helpers which will
allow to handle different sizes of OOB metadata on drive in the future.
Still, after this patch only OOB metadata equal to 16 bytes is supported.
On Wed, Nov 28, 2018 at 06:35:38AM -0700, Jens Axboe wrote:
> If we have that hook, we know the driver handles bd->last == true in
> a smart fashion. If it does, even for multiple hardware queues, it's
> a good idea to flush batches of requests to the device, if we have
> batches of requests from
On Wed, Nov 28, 2018 at 06:35:36AM -0700, Jens Axboe wrote:
> We need this for blk-mq to kick things into gear, if we told it that
> we had more IO coming, but then failed to deliver on that promise.
>
> Reviewed-by: Omar Sandoval
> Signed-off-by: Jens Axboe
> ---
> drivers/block/ataflop.c |
On Wed, Nov 28, 2018 at 06:35:37AM -0700, Jens Axboe wrote:
> If we are issuing a list of requests, we know if we're at the last one.
> If we fail issuing, ensure that we call ->commits_rqs() to flush any
> potential previous requests.
>
> Reviewed-by: Omar Sandoval
> Signed-off-by: Jens Axboe
On 11/28/18 8:27 PM, Ming Lei wrote:
> On Wed, Nov 28, 2018 at 08:13:43PM -0700, Jens Axboe wrote:
>> On 11/28/18 7:51 PM, Ming Lei wrote:
>>> On Wed, Nov 28, 2018 at 07:19:09PM -0700, Jens Axboe wrote:
On 11/28/18 6:23 PM, Ming Lei wrote:
> On Tue, Nov 27, 2018 at 07:34:51PM -0700, Jens
On Wed, Nov 28, 2018 at 08:13:43PM -0700, Jens Axboe wrote:
> On 11/28/18 7:51 PM, Ming Lei wrote:
> > On Wed, Nov 28, 2018 at 07:19:09PM -0700, Jens Axboe wrote:
> >> On 11/28/18 6:23 PM, Ming Lei wrote:
> >>> On Tue, Nov 27, 2018 at 07:34:51PM -0700, Jens Axboe wrote:
> On 11/27/18 7:10 PM,
On 11/28/18 7:51 PM, Ming Lei wrote:
> On Wed, Nov 28, 2018 at 07:19:09PM -0700, Jens Axboe wrote:
>> On 11/28/18 6:23 PM, Ming Lei wrote:
>>> On Tue, Nov 27, 2018 at 07:34:51PM -0700, Jens Axboe wrote:
On 11/27/18 7:10 PM, Ming Lei wrote:
> On Mon, Nov 26, 2018 at 09:35:53AM -0700, Jens
On Wed, Nov 28, 2018 at 07:19:09PM -0700, Jens Axboe wrote:
> On 11/28/18 6:23 PM, Ming Lei wrote:
> > On Tue, Nov 27, 2018 at 07:34:51PM -0700, Jens Axboe wrote:
> >> On 11/27/18 7:10 PM, Ming Lei wrote:
> >>> On Mon, Nov 26, 2018 at 09:35:53AM -0700, Jens Axboe wrote:
> We need this for
On 11/28/18 6:23 PM, Ming Lei wrote:
> On Tue, Nov 27, 2018 at 07:34:51PM -0700, Jens Axboe wrote:
>> On 11/27/18 7:10 PM, Ming Lei wrote:
>>> On Mon, Nov 26, 2018 at 09:35:53AM -0700, Jens Axboe wrote:
We need this for blk-mq to kick things into gear, if we told it that
we had more IO
On Tue, Nov 27, 2018 at 07:34:51PM -0700, Jens Axboe wrote:
> On 11/27/18 7:10 PM, Ming Lei wrote:
> > On Mon, Nov 26, 2018 at 09:35:53AM -0700, Jens Axboe wrote:
> >> We need this for blk-mq to kick things into gear, if we told it that
> >> we had more IO coming, but then failed to deliver on
On 2018/11/28 18:55, Johannes Thumshirn wrote:
> On 28/11/2018 02:25, Damien Le Moal wrote:
>> Jens Axboe , February 2009
>
> I guess that address of Jens' doesn't work anymore either.
>
Yes, I guess. I only updated my own email address...
--
Damien Le Moal
Western Digital Research
On 11/28/18 2:33 AM, Benny Halevy wrote:
>> I don't see how we can get there with it being larger than already,
>> that would be a big bug if we fill more events than userspace asked
>> for.
>>
>
> Currently we indeed can't, but if the code changes in the future and
> we do, this will reduce the
On Thu, 2018-11-29 at 00:54 +0800, Weiping Zhang wrote:
> add documentation for /sys/block//queue/io_timeout
>
> Signed-off-by: Weiping Zhang
> ---
> Documentation/ABI/testing/sysfs-block | 9 +
> Documentation/block/queue-sysfs.txt | 6 ++
> 2 files changed, 15 insertions(+)
>
>
add documentation for /sys/block//queue/io_timeout
Signed-off-by: Weiping Zhang
---
Documentation/ABI/testing/sysfs-block | 9 +
Documentation/block/queue-sysfs.txt | 6 ++
2 files changed, 15 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-block
On 11/28/18 9:13 AM, Bart Van Assche wrote:
> On Mon, 2018-11-19 at 22:11 +0800, Weiping Zhang wrote:
>> Give a interface to adjust io timeout by device.
>>
>> Signed-off-by: Weiping Zhang
>> ---
>>
>> Changes since v1:
>> * make sure timeout > 0
>>
>> block/blk-sysfs.c | 27
On Mon, 2018-11-19 at 22:11 +0800, Weiping Zhang wrote:
> Give a interface to adjust io timeout by device.
>
> Signed-off-by: Weiping Zhang
> ---
>
> Changes since v1:
> * make sure timeout > 0
>
> block/blk-sysfs.c | 27 +++
> 1 file changed, 27 insertions(+)
On 11/28/18 9:04 AM, Weiping Zhang wrote:
> Give a interface to adjust io timeout(ms) by device.
Looks good, applied.
--
Jens Axboe
On 11/28/18 1:42 AM, Yufen Yu wrote:
> We recently got a stack by syzkaller like this:
>
> BUG: sleeping function called from invalid context at mm/slab.h:361
> in_atomic(): 1, irqs_disabled(): 0, pid: 6644, name: blkid
> INFO: lockdep is turned off.
> CPU: 1 PID: 6644 Comm: blkid Not tainted
Give a interface to adjust io timeout(ms) by device.
Signed-off-by: Weiping Zhang
---
Changes since v2:
* use msecs_to_jiffies and jiffies_to_msecs
Changes since v1:
* make sure timeout > 0
block/blk-sysfs.c | 27 +++
1 file changed, 27 insertions(+)
diff --git
On 11/28/18 7:52 AM, Weiping Zhang wrote:
> Hi Jens,
>
> It's useful if user want a short timeout when a disk doesn't work normally.
> Would you give some comments for this patch,
I'm fine with the patch, in fact I've posted a similar/identical one in
the past but just never got around to
Hi Jens,
It's useful if user want a short timeout when a disk doesn't work normally.
Would you give some comments for this patch,
Thanks a lot
Weiping Zhang 于2018年11月19日周一 下午10:30写道：
>
> Give a interface to adjust io timeout by device.
>
> Signed-off-by: Weiping Zhang
> ---
>
> Changes since
On Wed, Nov 28, 2018 at 04:42:01PM +0800, Yufen Yu wrote:
> We recently got a stack by syzkaller like this:
>
> BUG: sleeping function called from invalid context at mm/slab.h:361
> in_atomic(): 1, irqs_disabled(): 0, pid: 6644, name: blkid
> INFO: lockdep is turned off.
> CPU: 1 PID: 6644 Comm:
We need this for blk-mq to kick things into gear, if we told it that
we had more IO coming, but then failed to deliver on that promise.
Reviewed-by: Omar Sandoval
Acked-by: Michael S. Tsirkin
Reviewed-by: Christoph Hellwig
Signed-off-by: Jens Axboe
---
drivers/block/virtio_blk.c | 15
We need this for blk-mq to kick things into gear, if we told it that
we had more IO coming, but then failed to deliver on that promise.
Reviewed-by: Omar Sandoval
Signed-off-by: Jens Axboe
---
drivers/block/ataflop.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
If we have that hook, we know the driver handles bd->last == true in
a smart fashion. If it does, even for multiple hardware queues, it's
a good idea to flush batches of requests to the device, if we have
batches of requests from the submitter.
Signed-off-by: Jens Axboe
---
block/blk-mq.c | 7
If we are issuing a list of requests, we know if we're at the last one.
If we fail issuing, ensure that we call ->commits_rqs() to flush any
potential previous requests.
Reviewed-by: Omar Sandoval
Signed-off-by: Jens Axboe
---
block/blk-core.c | 2 +-
block/blk-mq.c | 16
Split the command submission and the SQ doorbell ring, and add the
doorbell ring as our ->commit_rqs() hook. This allows a list of
requests to be issued, with nvme only writing the SQ update when
it's necessary. This is more efficient if we have lists of requests
to issue, particularly on
Only do it if we have requests for multiple queues in the same
plug.
Signed-off-by: Jens Axboe
---
block/blk-core.c | 1 +
block/blk-mq.c | 23 ++-
include/linux/blkdev.h | 1 +
3 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/block/blk-core.c
Series improving plugging for fast devices, but some fixes in here too.
Patch 1 changes the logic for when we sort the plug list, switching
it to only doing it if we have requests for multiple queues in the
plug (and enough requests to warrant an actual sort).
2-6 add a ->commit_rqs() hook and
blk-mq passes information to the hardware about any given request being
the last that we will issue in this sequence. The point is that hardware
can defer costly doorbell type writes to the last request. But if we run
into errors issuing a sequence of requests, we may never send the request
with
On 11/28/18 5:36 AM, Yang Xiao wrote:
> From: Young Xiao
>
> __vdc_tx_trigger should only loop on EAGAIN a finite
> number of times.
>
> See commit adddc32d6fde ("sunvnet: Do not spin in an
> infinite loop when vio_ldc_send() returns EAGAIN") for detail.
Looks good to me, applied.
--
Jens
On 11/28/18 12:26 AM, Christoph Hellwig wrote:
>> +} else if (plug && q->mq_ops->commit_rqs) {
>> +/*
>> + * If we have a ->commit_rqs(), then we know the driver can
>> + * batch submission doorbell updates. Add rq to plug list,
>> + * and flush
On 11/28/18 12:22 AM, Christoph Hellwig wrote:
> On Mon, Nov 26, 2018 at 09:35:54AM -0700, Jens Axboe wrote:
>> We need this for blk-mq to kick things into gear, if we told it that
>> we had more IO coming, but then failed to deliver on that promise.
>
> queue_rq also calls finish_fdc under
On 11/28/18 12:20 AM, Christoph Hellwig wrote:
>> +static inline int nvme_next_ring_index(struct nvme_queue *nvmeq, u16 index)
>> +{
>> +if (++index == nvmeq->q_depth)
>> +return 0;
>> +
>> +return index;
>
> Can you please just drop this helper? It makes the code not only
>
On 11/28/18 12:16 AM, Christoph Hellwig wrote:
> On Mon, Nov 26, 2018 at 09:35:51AM -0700, Jens Axboe wrote:
>> blk-mq passes information to the hardware about any given request being
>> the last that we will issue in this sequence. The point is that hardware
>> can defer costly doorbell type
On 28/11/2018 02:25, Damien Le Moal wrote:
> Jens Axboe , February 2009
I guess that address of Jens' doesn't work anymore either.
--
Johannes ThumshirnSUSE Labs
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH,
On Tue, 2018-11-27 at 08:24 -0700, Jens Axboe wrote:
> On 11/27/18 2:53 AM, Benny Halevy wrote:
> > > @@ -818,11 +853,15 @@ static int kill_ioctx(struct mm_struct *mm, struct
> > > kioctx *ctx,
> > > {
> > > struct kioctx_table *table;
> > >
> > > + mutex_lock(>getevents_lock);
> > >
We recently got a stack by syzkaller like this:
BUG: sleeping function called from invalid context at mm/slab.h:361
in_atomic(): 1, irqs_disabled(): 0, pid: 6644, name: blkid
INFO: lockdep is turned off.
CPU: 1 PID: 6644 Comm: blkid Not tainted 4.4.163-514.55.6.9.x86_64+ #76
Hardware name: QEMU
On Fri, Nov 16, 2018 at 02:08:05PM +0100, Christoph Hellwig wrote:
> This allows tools like distro installers easily track the relationship.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/nvme/host/core.c | 5 +++--
> drivers/nvme/host/multipath.c | 12 ++--
>
44 matches
Mail list logo
