On 24 January 2017 at 11:17, Linus Walleij wrote:
> The function mmc_blk_issue_rw_rq() is hopelessly convoluted and
> need to be refactored to it can be understood by humans.
>
> In the process I found some weird magic return values passed
> around for no good reason.
>
> Things are more readable
On Wed, Jan 25, 2017 at 03:36:20PM -0600, Eric Blake wrote:
> How do you get an fd to existing nbd block device? Your intent is to
> use an ioctl to request creating/opening a new nbd device that no one
> else is using; opening an existing device in order to send that ioctl
> may have negative ram
On Thu, Jan 26, 2017 at 12:40:47AM -0800, Christoph Hellwig wrote:
> On Wed, Jan 25, 2017 at 03:36:20PM -0600, Eric Blake wrote:
> > How do you get an fd to existing nbd block device? Your intent is to
> > use an ioctl to request creating/opening a new nbd device that no one
> > else is using; ope
On Wed 25-01-17 13:43:58, Dan Williams wrote:
> On Mon, Jan 23, 2017 at 1:17 PM, Thiago Jung Bauermann
> wrote:
> > Hello Dan,
> >
> > Am Freitag, 6. Januar 2017, 17:02:51 BRST schrieb Dan Williams:
> >> v1 of these changes [1] was a one line change to bdev_get_queue() to
> >> prevent a shutdown c
Until now erases has been submitted as synchronous commands through a
dedicated erase function. In order to allow targets implementing
asynchronous erases, refactor the erase path so that it uses the normal
async I/O submission path. If a target requires sync I/O, it can
implement it internally. Al
Let the host differentiate between a read error and a CRC check error on
the device side.
Signed-off-by: Javier González
---
include/linux/lightnvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/lightnvm.h b/include/linux/lightnvm.h
index 11c318e..51cda67 100644
--- a/includ
In order to register through the sysfs interface, a driver needs to know
its kobject. On a disk structure, this happens when the partition
information is added (device_add_disk), which for lightnvm takes place
after the target has been initialized. This means that on target
initialization, the kboj
These flags are in use for filesystems with backing storage: PG_error,
PG_writeback and PG_readahead.
Signed-off-by: Kirill A. Shutemov
---
include/linux/page-flags.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/page-flags.h b/include/linux/page-fl
As the function handles zeroing range only within one block, the
required changes are trivial, just remove assuption on page size.
Signed-off-by: Kirill A. Shutemov
---
fs/ext4/inode.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
in
We want page to be isolated from the rest of the system before splitting
it. We rely on page count to be 2 for file pages to make sure nobody
uses the page: one pin to caller, one to radix-tree.
Filesystems with backing storage can have page count increased if it has
buffers.
Let's try to free th
It's more or less straight-forward.
Most changes are around getting offset/len withing page right and zero
out desired part of the page.
Signed-off-by: Kirill A. Shutemov
---
fs/buffer.c | 70 +++--
1 file changed, 40 insertions(+), 30 del
Here's respin of my huge ext4 patchset on top v4.10-rc/5 + my recent
patchset that fixes rmap-related THP bugs. That patchset also bring
required for huge-ext4 page_mkclean() changes.
Please review and consider applying.
I don't see any xfstests regressions with huge pages enabled. Patch with
new
For filesystems that wants to be write-notified (has mkwrite), we will
encount write-protection faults for huge PMDs in shared mappings.
The easiest way to handle them is to clear the PMD and let it refault as
wriable.
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Jan Kara
---
mm/memory.c | 1
__ext4_block_zero_page_range() adjusted to calculate starting iblock
correctry for huge pages.
ext4_{collapse,insert}_range() requires page cache invalidation. We need
the invalidation to be aligning to huge page border if huge pages are
possible in page cache.
Signed-off-by: Kirill A. Shutemov
Adjust how we find relevant block within page and how we clear the
required part of the page.
Signed-off-by: Kirill A. Shutemov
---
fs/ext4/move_extent.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/move_extent.c b/fs/ext4/move_extent.c
index 6fc14def0
For huge pages 'stop' must be within HPAGE_PMD_SIZE.
Let's use hpage_size() in the BUG_ON().
We also need to change how we calculate lblk for cluster deallocation.
Signed-off-by: Kirill A. Shutemov
---
fs/ext4/inode.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/e
As BIO_MAX_PAGES is smaller (on x86) than HPAGE_PMD_NR, we cannot use
the optimization ext4_mpage_readpages() provides.
So, for huge pages, we fallback directly to block_read_full_page().
This should be re-visited once we get multipage bvec upstream.
Signed-off-by: Kirill A. Shutemov
---
fs/ex
Introduce new helpers which return size/mask of the page:
HPAGE_PMD_SIZE/HPAGE_PMD_MASK if the page is PageTransHuge() and
PAGE_SIZE/PAGE_MASK otherwise.
Signed-off-by: Kirill A. Shutemov
---
include/linux/huge_mm.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/li
It simply matches changes to __block_write_begin_int().
Signed-off-by: Kirill A. Shutemov
---
fs/ext4/inode.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 7e65a5b78cf1..3eae2d058fd0 100644
--- a/
We would need to use multi-order radix-tree entires for ext4 and other
filesystems to have coherent view on tags (dirty/towrite) in the tree.
This patch converts huge tmpfs implementation to multi-order entries, so
we will be able to use the same code patch for all filesystems.
We also change int
This reverts commit 356e1c23292a4f63cfdf1daf0e0ddada51f32de8.
After conversion of huge tmpfs to multi-order entries, we don't need
this anymore.
Signed-off-by: Kirill A. Shutemov
---
include/linux/radix-tree.h | 1 -
lib/radix-tree.c | 74 -
ext4_find_unwritten_pgoff() needs few tweaks to work with huge pages.
Mostly trivial page_mapping()/page_to_pgoff() and adjustment to how we
find relevant block.
Signe-off-by: Kirill A. Shutemov
---
fs/ext4/file.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --
With huge pages in page cache we see tail pages in more code paths.
This patch replaces direct access to struct page fields with macros
which can handle tail pages properly.
Signed-off-by: Kirill A. Shutemov
---
fs/buffer.c | 2 +-
fs/ext4/inode.c | 4 ++--
mm/filemap.c| 24
The same four values as in tmpfs case.
Encyption code is not yet ready to handle huge page, so we disable huge
pages support if the inode has EXT4_INODE_ENCRYPT.
Signed-off-by: Kirill A. Shutemov
---
fs/ext4/ext4.h | 5 +
fs/ext4/inode.c | 32 +++-
fs/ext4/supe
We writeback whole huge page a time. Let's adjust iteration this way.
Signed-off-by: Kirill A. Shutemov
---
include/linux/mm.h | 1 +
include/linux/pagemap.h | 1 +
mm/page-writeback.c | 17 -
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/include/linu
Adjust check on whether part of the page beyond file size and apply
compound_head() and page_mapping() where appropriate.
Signed-off-by: Kirill A. Shutemov
---
fs/buffer.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index d05524f14846.
For huge pages we need to unmap whole range covered by the huge page.
Signed-off-by: Kirill A. Shutemov
---
mm/truncate.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/mm/truncate.c b/mm/truncate.c
index 81e1a13acb63..ddb615e6a193 100644
--- a/mm/tr
Call ext4_da_should_update_i_disksize() for head page with offset
relative to head page.
Signed-off-by: Kirill A. Shutemov
---
fs/ext4/inode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 3eae2d058fd0..bdd62dcaa0b2 100644
---
If huge pages enabled, in worst case with 2048 blocks underlying a page,
each possibly in a different block group we have much more metadata to
commit.
Let's update estimates accordingly.
I was not able to trigger bad situation without the patch as it's hard to
construct very fragmented filesyste
We need to account huge pages according to its size to get background
writaback work properly.
Signed-off-by: Kirill A. Shutemov
---
fs/fs-writeback.c | 10 +++---
include/linux/backing-dev.h | 10 ++
include/linux/memcontrol.h | 22 ++---
mm/migrate.c| 1
As with shmem_undo_range(), truncate_inode_pages_range() removes huge
pages, if it fully within range.
Partial truncate of huge pages zero out this part of THP.
Unlike with shmem, it doesn't prevent us having holes in the middle of
huge page we still can skip writeback not touched buffers.
With
The approach is straight-forward: for compound pages we read out whole
huge page.
For huge page we cannot have array of buffer head pointers on stack --
it's 4096 pointers on x86-64 -- 'arr' is allocated with kmalloc() for
huge pages.
Signed-off-by: Kirill A. Shutemov
---
fs/buffer.c
Most of work happans on head page. Only when we need to do copy data to
userspace we find relevant subpage.
We are still limited by PAGE_SIZE per iteration. Lifting this limitation
would require some more work.
Signed-off-by: Kirill A. Shutemov
---
mm/filemap.c | 5 -
1 file changed, 4 inse
Most page cache allocation happens via readahead (sync or async), so if
we want to have significant number of huge pages in page cache we need
to find a ways to allocate them from readahead.
Unfortunately, huge pages doesn't fit into current readahead design:
128 max readahead window, assumption o
Modify mpage_map_and_submit_buffers() and mpage_release_unused_pages()
to deal with huge pages.
Mostly result of try-and-error. Critical view would be appreciated.
Signed-off-by: Kirill A. Shutemov
---
fs/ext4/inode.c | 61 -
1 file change
Slab pages can be compound, but we shouldn't threat them as THP for
pupose of hpage_* helpers, otherwise it would lead to confusing results.
For instance, ext4 uses slab pages for journal pages and we shouldn't
confuse them with THPs. The easiest way is to exclude them in hpage_*
helpers.
Signed-
Trivial: remove assumption on page size.
Signed-off-by: Kirill A. Shutemov
---
fs/ext4/inode.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 8d1b5e63cb15..a25be1cf4506 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@
We want mmap(NULL) to return PMD-aligned address if the inode can have
huge pages in page cache.
Signed-off-by: Kirill A. Shutemov
---
mm/huge_memory.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 55aee62e8444..2b1d8d13e2c3 1006
We writeback whole huge page a time.
Signed-off-by: Kirill A. Shutemov
---
mm/filemap.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/mm/filemap.c b/mm/filemap.c
index 4e398d5e4134..f5cd654b3662 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -405,9 +405,14 @@ static int __filemap_fda
This patch adds basic functionality to put huge page into page cache.
At the moment we only put huge pages into radix-tree if the range covered
by the huge page is empty.
We ignore shadow entires for now, just remove them from the tree before
inserting huge page.
Later we can add logic to accumu
Change ext4_writepage() and underlying ext4_bio_write_page().
It basically removes assumption on page size, infer it from struct page
instead.
Signed-off-by: Kirill A. Shutemov
---
fs/ext4/inode.c | 10 +-
fs/ext4/page-io.c | 11 +--
2 files changed, 14 insertions(+), 7 deleti
Do not assume length of bio segment is never larger than PAGE_SIZE.
With huge pages it's HPAGE_PMD_SIZE (2M on x86-64).
Signed-off-by: Kirill A. Shutemov
---
drivers/block/brd.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/block/brd.c b/drivers/b
Write path allocate pages using pagecache_get_page(). We should be able
to allocate huge pages there, if it's allowed. As usually, fallback to
small pages, if failed.
Signed-off-by: Kirill A. Shutemov
---
mm/filemap.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff
From: Naoya Horiguchi
Currently, hugetlb pages are linked to page cache on the basis of hugepage
offset (derived from vma_hugecache_offset()) for historical reason, which
doesn't match to the generic usage of page cache and requires some routines
to covert page offset <=> hugepage offset in commo
Let's add FileHugePages and FilePmdMapped fields into meminfo and smaps.
It indicates how many times we allocate and map file THP.
Signed-off-by: Kirill A. Shutemov
---
drivers/base/node.c| 6 ++
fs/proc/meminfo.c | 4
fs/proc/task_mmu.c | 5 -
include/linux/mmzone.h
On Thu, Jan 26, 2017 at 10:17:58AM +0100, Greg KH wrote:
> Ok, but do you feel the "loop method" of using a char device node to
> create/control these devices is a good model to follow for new devices
> like ndb?
Yes. We've done the same for NVMe over fabrics.
--
To unsubscribe from this list: sen
On Thu, Jan 26, 2017 at 11:06:53AM +0100, Jan Kara wrote:
> Yeah, so my patches (and I suspect your as well), have a problem when the
> backing_device_info stays around because blkdev inode still exists, device
> gets removed (e.g. USB disk gets unplugged) but blkdev inode still stays
> around (the
> Il giorno 25 gen 2017, alle ore 17:13, Jens Axboe ha scritto:
>
> On 01/25/2017 01:46 AM, Paolo Valente wrote:
>>
>>> Il giorno 23 gen 2017, alle ore 18:42, Jens Axboe ha scritto:
>>>
>>> On 01/23/2017 10:04 AM, Paolo Valente wrote:
> Il giorno 18 gen 2017, alle ore 17:21, Jens Ax
On Wed, Jan 25, 2017 at 10:23 AM, Mateusz Nowak
wrote:
> On 1/24/2017 11:17, Linus Walleij wrote:
>>
>> As a first step toward breaking apart the very complex function
>> mmc_blk_issue_rw_rq() we break out the command abort code.
>> This code assumes "ret" is != 0 and then repeatedly hammers
>> bl
The mmc_blk_rw_start_new() was named after the label inside
mmc_blk_issue_rw_rq() but is really a confusing name for this
function: what it does is to try to restart the latest issued
command on the host and card of the current MMC queue.
So rename it mmc_blk_rw_try_restart() that reflects what it
The mmc_active member of struct mmc_queue_req has a very
confusing name: this is certainly not always "active", it is
the asynchronous request associated by the mmc_queue_req
but it is not guaranteed to be "active" in any sense, such
as being running on the host.
Simply rename this member to "areq
The goto statements sprinkled over the mmc_blk_issue_rw_rq()
function has grown over the years and makes the code pretty hard
to read.
Inline the calls such that:
goto cmd_abort; ->
mmc_blk_rw_cmd_abort(card, req);
mmc_blk_rw_start_new(mq, card, rqc);
return;
goto start_new_req; ->
mmc_blk_rw_st
Instead of masking and setting two bits in the "flags" field
for the mmc_queue, just use two bools named "suspended" and
"new_request".
The masking and setting would likely have race conditions
anyways, it is better to use a simple member like this.
Signed-off-by: Linus Walleij
---
drivers/mmc/
With the coexisting __mmc_start_request(), mmc_start_request()
and __mmc_start_req() it is a bit confusing that mmc_start_req()
actually does not start a normal request, but an asynchronous
request.
Rename it to mmc_start_areq() to make it explicit what the
function is doing, also fix the kerneldo
In the function mmc_blk_issue_rw_rq() the new request coming in
from the block layer is called "rqc" and the old request that
was potentially just returned back from the asynchronous
mechanism is called "req".
This is really confusing when trying to analyze and understand
the code, it becomes a pe
On Thu, Jan 26, 2017 at 02:57:44PM +0300, Kirill A. Shutemov wrote:
> This reverts commit 356e1c23292a4f63cfdf1daf0e0ddada51f32de8.
>
> After conversion of huge tmpfs to multi-order entries, we don't need
> this anymore.
Yay! Reviewed-by: Matthew Wilcox
--
To unsubscribe from this list: send th
On Thu, Jan 26, 2017 at 02:57:48PM +0300, Kirill A. Shutemov wrote:
> For filesystems that wants to be write-notified (has mkwrite), we will
> encount write-protection faults for huge PMDs in shared mappings.
>
> The easiest way to handle them is to clear the PMD and let it refault as
> wriable.
On Thu, Jan 26, 2017 at 07:44:39AM -0800, Matthew Wilcox wrote:
> On Thu, Jan 26, 2017 at 02:57:48PM +0300, Kirill A. Shutemov wrote:
> > For filesystems that wants to be write-notified (has mkwrite), we will
> > encount write-protection faults for huge PMDs in shared mappings.
> >
> > The easiest
Fix a memory leak when target creation fails. More specifically, free
the entire device structure given to the target (tgt_dev).
Signed-off-by: Javier González
---
drivers/lightnvm/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/lightnvm/core.c b/drivers/lightn
On Thu, Jan 26, 2017 at 5:17 AM, Christoph Hellwig wrote:
> On Thu, Jan 26, 2017 at 11:06:53AM +0100, Jan Kara wrote:
>> Yeah, so my patches (and I suspect your as well), have a problem when the
>> backing_device_info stays around because blkdev inode still exists, device
>> gets removed (e.g. USB
On 01/26/2017 09:35 AM, Hannes Reinecke wrote:
> On 01/25/2017 11:27 PM, Jens Axboe wrote:
>> On 01/25/2017 10:42 AM, Jens Axboe wrote:
>>> On 01/25/2017 10:03 AM, Jens Axboe wrote:
On 01/25/2017 09:57 AM, Hannes Reinecke wrote:
> On 01/25/2017 04:52 PM, Jens Axboe wrote:
>> On 01/25/2
On 01/25/2017 11:27 PM, Jens Axboe wrote:
> On 01/25/2017 10:42 AM, Jens Axboe wrote:
>> On 01/25/2017 10:03 AM, Jens Axboe wrote:
>>> On 01/25/2017 09:57 AM, Hannes Reinecke wrote:
On 01/25/2017 04:52 PM, Jens Axboe wrote:
> On 01/25/2017 04:10 AM, Hannes Reinecke wrote:
[ .. ]
>
Hello,
this patch series attempts to solve the problems with the life time of a
backing_dev_info structure. Currently it lives inside request_queue structure
and thus it gets destroyed as soon as request queue goes away. However
the block device inode still stays around and thus inode_to_bdi() cal
We will want to have struct backing_dev_info allocated separately from
struct request_queue. As the first step add pointer to backing_dev_info
to request_queue and convert all users touching it. No functional
changes in this patch.
Signed-off-by: Jan Kara
---
block/blk-cgroup.c | 6
Currenly blk_get_backing_dev_info() is not safe to be called when the
block device is not open as bdev->bd_disk is NULL in that case. However
inode_to_bdi() uses this function and may be call called from flusher
worker or other writeback related functions without bdev being open
which leads to cras
Currently, block device inodes stay around after corresponding gendisk
hash died until memory reclaim finds them and frees them. Since we will
make block device inode pin the bdi, we want to free the block device
inode as soon as the device goes away so that bdi does not stay around
unnecessarily.
Instead of storing backing_dev_info inside struct request_queue,
allocate it dynamically, reference count it, and free it when the last
reference is dropped. Currently only request_queue holds the reference
but in the following patch we add other users referencing
backing_dev_info.
Signed-off-by:
On Wed, 2017-01-25 at 18:25 +0100, Christoph Hellwig wrote:
> Hi all,
>
> this series splits the support for SCSI passthrough commands from the
> main struct request used all over the block layer into a separate
> scsi_request structure that drivers that want to support SCSI passthough
> need to e
On Thu, 2017-01-26 at 11:44 -0700, Jens Axboe wrote:
> I think this may be my bug - does the below help?
Hello Jens,
What tree has that patch been generated against? It does not apply
cleanly on top of Christoph's tree:
$ git checkout hch-block-pc-refactor
$ patch -p1 --dry-run -f -s <
~/Re\:_s
On 01/26/2017 11:52 AM, Bart Van Assche wrote:
> On Thu, 2017-01-26 at 11:44 -0700, Jens Axboe wrote:
>> I think this may be my bug - does the below help?
>
> Hello Jens,
>
> What tree has that patch been generated against? It does not apply
> cleanly on top of Christoph's tree:
>
> $ git checko
On Thu, Jan 26, 2017 at 11:57:36AM -0700, Jens Axboe wrote:
> It's against my for-4.11/block, which you were running under Christoph's
> patches. Maybe he's using an older version? In any case, should be
> pretty trivial for you to hand apply. Just ensure that .flags is set to
> 0 for the common ca
On 01/23/2017 07:29 AM, Christoph Hellwig wrote:
> +int scsi_cmd_buf_len(struct request *rq)
> +{
> + return scsi_req(rq)->cmd_len * 3;
> +}
> +EXPORT_SYMBOL(scsi_cmd_buf_len);
Hello Christoph,
Where does the '* 3' come from? I think that deserves a comment.
Additionally, this patch introduce
On 01/26/2017 09:42 AM, Jens Axboe wrote:
> On 01/26/2017 09:35 AM, Hannes Reinecke wrote:
>> On 01/25/2017 11:27 PM, Jens Axboe wrote:
>>> On 01/25/2017 10:42 AM, Jens Axboe wrote:
On 01/25/2017 10:03 AM, Jens Axboe wrote:
> On 01/25/2017 09:57 AM, Hannes Reinecke wrote:
>> On 01/25/2
On Thu, Jan 26, 2017 at 11:12:51AM -0800, Bart Van Assche wrote:
> Where does the '* 3' come from? I think that deserves a comment.
> Additionally, this patch introduces a new warning when building with W=1:
It's a magic factor copied from the old code :(
That beeing said I really wonder if we sh
On 01/26/2017 12:37 PM, Christoph Hellwig wrote:
> On Thu, Jan 26, 2017 at 11:12:51AM -0800, Bart Van Assche wrote:
>> Where does the '* 3' come from? I think that deserves a comment.
>> Additionally, this patch introduces a new warning when building with W=1:
>
> It's a magic factor copied from t
Once we mark the queue as needing a restart, re-check if we can
get a driver tag. This fixes a theoretical issue where the needed
IO completes _after_ blk_mq_get_driver_tag() fails, but before we
manage to set the restart bit.
Signed-off-by: Jens Axboe
---
block/blk-mq.c | 9 +
1 file ch
I've been diving into the problems that Hannes reported, both the
stalls related to shared tag maps and multiple hardware queues,
but also the cases where we get suboptimal merging.
This series attempts to fix that.
Hannes, this should be identical to what I sent you as a bundled up
patch earlier
When we invoke dispatch_requests(), the scheduler empties everything
into the passed in list. This isn't always a good thing, since it
means that we remove items that we could have potentially merged
with.
Change the function to dispatch single requests at the time. If
we do that, we can backoff e
We don't want to hold on to this resource when we have a scheduler
attached.
Signed-off-by: Jens Axboe
---
block/blk-mq.c | 16
1 file changed, 16 insertions(+)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 8041ad330289..089b2eedca4f 100644
--- a/block/blk-mq.c
+++ b/block
If we have both multiple hardware queues and shared tag map between
devices, we need to ensure that we propagate the hardware queue
restart bit higher up. This is because we can get into a situation
where we don't have any IO pending on a hardware queue, yet we fail
getting a tag to start new IO. I
We'll use the same criteria for whether we need to run the queue sync
or async when we have a scheduler, as we do without one.
Signed-off-by: Jens Axboe
---
block/blk-mq.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 84d13b5cafd0
On 01/26/2017 12:48 PM, Jens Axboe wrote:
> Once we mark the queue as needing a restart, re-check if we can
> get a driver tag. This fixes a theoretical issue where the needed
> IO completes _after_ blk_mq_get_driver_tag() fails, but before we
> manage to set the restart bit.
>
> Signed-off-by: Je
On 01/26/2017 11:29 AM, Bart Van Assche wrote:
> On Wed, 2017-01-25 at 18:25 +0100, Christoph Hellwig wrote:
>> Hi all,
>>
>> this series splits the support for SCSI passthrough commands from the
>> main struct request used all over the block layer into a separate
>> scsi_request structure that dri
On Thu, Jan 26, 2017 at 12:52:15PM -0700, Jens Axboe wrote:
> I screwed this up when splitting up the patchset, that last break needs to
> be removed as well, of course. Updated below:
>
>
> From 9d68cf9232c06a793e305d10b6d655df4beae928 Mon Sep 17 00:00:00 2001
> From: Jens Axboe
> Date: Thu, 26
On Thu, Jan 26, 2017 at 12:48:16PM -0700, Jens Axboe wrote:
> We don't want to hold on to this resource when we have a scheduler
> attached.
Reviewed-by: Omar Sandoval
> Signed-off-by: Jens Axboe
> ---
> block/blk-mq.c | 16
> 1 file changed, 16 insertions(+)
--
To unsubscribe
On Thu, Jan 26, 2017 at 12:48:14PM -0700, Jens Axboe wrote:
> We'll use the same criteria for whether we need to run the queue sync
> or async when we have a scheduler, as we do without one.
Reviewed-by: Omar Sandoval
> Signed-off-by: Jens Axboe
> ---
> block/blk-mq.c | 6 --
> 1 file chan
On 01/26/2017 01:25 PM, Omar Sandoval wrote:
> On Thu, Jan 26, 2017 at 12:48:17PM -0700, Jens Axboe wrote:
>> If we have both multiple hardware queues and shared tag map between
>> devices, we need to ensure that we propagate the hardware queue
>> restart bit higher up. This is because we can get i
On Thu, Jan 26, 2017 at 12:48:17PM -0700, Jens Axboe wrote:
> If we have both multiple hardware queues and shared tag map between
> devices, we need to ensure that we propagate the hardware queue
> restart bit higher up. This is because we can get into a situation
> where we don't have any IO pendi
On Thu, Jan 26, 2017 at 9:45 AM, Jan Kara wrote:
> Instead of storing backing_dev_info inside struct request_queue,
> allocate it dynamically, reference count it, and free it when the last
> reference is dropped. Currently only request_queue holds the reference
> but in the following patch we add
On 01/26/2017 11:59 AM, h...@lst.de wrote:
> On Thu, Jan 26, 2017 at 11:57:36AM -0700, Jens Axboe wrote:
>> It's against my for-4.11/block, which you were running under Christoph's
>> patches. Maybe he's using an older version? In any case, should be
>> pretty trivial for you to hand apply. Just en
On 01/26/2017 11:01 AM, Jens Axboe wrote:
> On 01/26/2017 11:59 AM, h...@lst.de wrote:
>> On Thu, Jan 26, 2017 at 11:57:36AM -0700, Jens Axboe wrote:
>>> It's against my for-4.11/block, which you were running under Christoph's
>>> patches. Maybe he's using an older version? In any case, should be
>
On Thu, Jan 26, 2017 at 12:48:18PM -0700, Jens Axboe wrote:
> When we invoke dispatch_requests(), the scheduler empties everything
> into the passed in list. This isn't always a good thing, since it
> means that we remove items that we could have potentially merged
> with.
>
> Change the function
On 01/26/2017 01:47 PM, Bart Van Assche wrote:
> On 01/26/2017 11:01 AM, Jens Axboe wrote:
>> On 01/26/2017 11:59 AM, h...@lst.de wrote:
>>> On Thu, Jan 26, 2017 at 11:57:36AM -0700, Jens Axboe wrote:
It's against my for-4.11/block, which you were running under Christoph's
patches. Maybe
On 01/26/2017 01:54 PM, Omar Sandoval wrote:
> On Thu, Jan 26, 2017 at 12:48:18PM -0700, Jens Axboe wrote:
>> When we invoke dispatch_requests(), the scheduler empties everything
>> into the passed in list. This isn't always a good thing, since it
>> means that we remove items that we could have po
On Thu, 2017-01-26 at 13:54 -0700, Jens Axboe wrote:
> Your call path has blk_get_request() in it, I don't have
> that in my tree. Is it passing in the right mask?
Hello Jens,
There is only one blk_get_request() call in drivers/md/dm-mpath.c
and it looks as follows:
clone = blk_get_reque
On Thu, Jan 26, 2017 at 01:59:23PM -0700, Jens Axboe wrote:
> On 01/26/2017 01:54 PM, Omar Sandoval wrote:
> > On Thu, Jan 26, 2017 at 12:48:18PM -0700, Jens Axboe wrote:
> >> When we invoke dispatch_requests(), the scheduler empties everything
> >> into the passed in list. This isn't always a good
On 01/26/2017 02:11 PM, Omar Sandoval wrote:
> On Thu, Jan 26, 2017 at 01:59:23PM -0700, Jens Axboe wrote:
>> On 01/26/2017 01:54 PM, Omar Sandoval wrote:
>>> On Thu, Jan 26, 2017 at 12:48:18PM -0700, Jens Axboe wrote:
When we invoke dispatch_requests(), the scheduler empties everything
i
On 01/26/2017 02:01 PM, Bart Van Assche wrote:
> On Thu, 2017-01-26 at 13:54 -0700, Jens Axboe wrote:
>> Your call path has blk_get_request() in it, I don't have
>> that in my tree. Is it passing in the right mask?
>
> Hello Jens,
>
> There is only one blk_get_request() call in drivers/md/dm-mpat
On Thu, 2017-01-26 at 14:12 -0700, Jens Axboe wrote:
> On 01/26/2017 02:01 PM, Bart Van Assche wrote:
> > On Thu, 2017-01-26 at 13:54 -0700, Jens Axboe wrote:
> > > Your call path has blk_get_request() in it, I don't have
> > > that in my tree. Is it passing in the right mask?
> >
> > Hello Jens,
Opened a bug -> https://bugzilla.kernel.org/show_bug.cgi?id=193331
tried multiple linux levels (4.4.21, 4.7, 4.9.5) (gentoo-sources).
Have been testing using the 4.9.5-gentoo sources kernel.
Might possible be a btrfs issue, but in an IRC chat with one of the
gentoo linux-kernel folks, they sugg
1 - 100 of 116 matches
Mail list logo