On 2017年01月27日 16:16, Christoph Hellwig wrote:
Try to grab the MSI-X vectors early and fall back to the shared one
before doing lots of allocations.
Signed-off-by: Christoph Hellwig
---
Reviewed-by: Jason Wang
drivers/virtio/virtio_pci_common.c | 58 +++-
I found following ext4 error occurs on a certain storage since v4.10-rc1:
EXT4-fs (sdc1): Delayed block allocation failed for inode 12 at logical
offset 100 with max blocks 2 with error 121
EXT4-fs (sdc1): This should not happen!! Data will be lost
Error 121 (EREMOTEIO) was returned from blkd
On 2017年01月27日 16:16, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig
---
Reviewed-by: Jason Wang
drivers/virtio/virtio_pci_common.c | 5 ++---
drivers/virtio/virtio_pci_common.h | 2 --
drivers/virtio/virtio_pci_legacy.c | 2 +-
drivers/virtio/virtio_pci_modern.c | 2 +-
On 2017年01月27日 16:16, Christoph Hellwig wrote:
We don't really need struct virtio_pci_vq_info, as most field in there
are redundant:
- the vq backpointer is not strictly neede to start with
- the entry in the vqs list is not needed - the generic virtqueue already
has list, we only need
On 2017年01月27日 16:16, Christoph Hellwig wrote:
+ snprintf(vp_dev->msix_names[i + 1],
+sizeof(*vp_dev->msix_names), "%s-%s",
dev_name(&vp_dev->vdev.dev), names[i]);
err = request_irq(pci_irq_vector(vp_dev->pci_dev, ms
On Thu, Feb 02 2017 at 7:20pm -0500,
Bart Van Assche wrote:
> On Thu, 2017-02-02 at 16:10 -0500, Mike Snitzer wrote:
> > Care to try moving the dm_get(md) at the end of dm_start_request() to
> > the beginning of dm_start_request() and report back on whether it helps
> > at all?
>
> Hello Mike,
On Thu, 2017-02-02 at 16:10 -0500, Mike Snitzer wrote:
> Care to try moving the dm_get(md) at the end of dm_start_request() to
> the beginning of dm_start_request() and report back on whether it helps
> at all?
Hello Mike,
Sorry but I don't see how that could make a difference. While we are at it
On 02/02/2017 04:42 PM, Omar Sandoval wrote:
> From: Omar Sandoval
>
> There's a weird inconsistency that flushes are mostly hidden from the
> scheduler, but it needs to be aware of them in ->insert_requests().
> Instead of having every scheduler call blk_mq_sched_bypass_insert(),
> let's do it i
On 02/02/2017 04:40 PM, Bart Van Assche wrote:
> Hello Jens,
>
> I noticed accidentally that with the for-next branch of the block
> git repository that the zram driver doesn't build anymore:
>
>
> $ make M=drivers/block/zram
> LD drivers/block/zram/built-in.o
> CC [M] drivers/block/zr
From: Omar Sandoval
There's a weird inconsistency that flushes are mostly hidden from the
scheduler, but it needs to be aware of them in ->insert_requests().
Instead of having every scheduler call blk_mq_sched_bypass_insert(),
let's do it in the common framework.
Signed-off-by: Omar Sandoval
--
Hello Jens,
I noticed accidentally that with the for-next branch of the block
git repository that the zram driver doesn't build anymore:
$ make M=drivers/block/zram
LD drivers/block/zram/built-in.o
CC [M] drivers/block/zram/zcomp.o
CC [M] drivers/block/zram/zram_drv.o
drivers/block/
On Thu, 2017-02-02 at 16:04 -0500, Mike Snitzer wrote:
> Any progress on getting this to work without requiring infiniband HW?
Hello Mike,
Intructions for running these tests over SoftRoCE have been added to
the README.md file in https://github.com/bvanassche/srp-test. However,
I'm not sure the S
On 02/02/2017 02:15 PM, Paolo Valente wrote:
>
>> Il giorno 02 feb 2017, alle ore 16:30, Jens Axboe ha scritto:
>>
>> On 02/02/2017 02:19 AM, Paolo Valente wrote:
>>> The scheme is clear. One comment, in case it could make sense and
>>> avoid more complexity: since put_rq_priv is invoked in two
> Il giorno 02 feb 2017, alle ore 16:30, Jens Axboe ha scritto:
>
> On 02/02/2017 02:19 AM, Paolo Valente wrote:
>> The scheme is clear. One comment, in case it could make sense and
>> avoid more complexity: since put_rq_priv is invoked in two different
>> contexts, process or interrupt, I didn
On Thu, Feb 02 2017 at 4:04pm -0500,
Mike Snitzer wrote:
> On Thu, Feb 02 2017 at 2:46pm -0500,
> Bart Van Assche wrote:
>
> > On Thu, 2017-02-02 at 14:13 -0500, Mike Snitzer wrote:
> > > On Thu, Feb 02 2017 at 1:43pm -0500, Bart Van Assche
> > > wrote:
> > > > On Thu, 2017-02-02 at 13:33
On Thu, Feb 02 2017 at 2:46pm -0500,
Bart Van Assche wrote:
> On Thu, 2017-02-02 at 14:13 -0500, Mike Snitzer wrote:
> > On Thu, Feb 02 2017 at 1:43pm -0500, Bart Van Assche
> > wrote:
> > > On Thu, 2017-02-02 at 13:33 -0500, Mike Snitzer wrote:
> > > > I'll go back over hch's changes to see
Jan,
Am 02.02.2017 um 18:34 schrieb Jan Kara:
> Allocate struct backing_dev_info separately instead of embedding it
> inside the superblock. This unifies handling of bdi among users.
>
> CC: Richard Weinberger
> CC: Artem Bityutskiy
> CC: Adrian Hunter
> CC: linux-...@lists.infradead.org
> Sig
On Thu, 2017-02-02 at 14:13 -0500, Mike Snitzer wrote:
> On Thu, Feb 02 2017 at 1:43pm -0500, Bart Van Assche
> wrote:
> > On Thu, 2017-02-02 at 13:33 -0500, Mike Snitzer wrote:
> > > I'll go back over hch's changes to see if I can spot anything. But is
> > > this testing using dm_mod.use_bk_mq
Hi,
On Thu, Feb 02, 2017 at 06:34:02PM +0100, Jan Kara wrote:
> Provide helper functions for setting up dynamically allocated
> backing_dev_info structures for filesystems and cleaning them up on
> superblock destruction.
Just one concern, will this cause problems for multiple superblock cases
li
On Thu, Feb 02 2017 at 1:43pm -0500,
Bart Van Assche wrote:
> On Thu, 2017-02-02 at 13:33 -0500, Mike Snitzer wrote:
> > I'll go back over hch's changes to see if I can spot anything. But is
> > this testing using dm_mod.use_bk_mq=Y or are you testing old .request_fn
> > dm-multipath?
>
> Hell
On Thu, 2017-02-02 at 13:33 -0500, Mike Snitzer wrote:
> I'll go back over hch's changes to see if I can spot anything. But is
> this testing using dm_mod.use_bk_mq=Y or are you testing old .request_fn
> dm-multipath?
Hello Mike,
The srp-test software tests multiple configurations: dm-mq on scsi
On Thu, Feb 02 2017 at 12:27pm -0500,
Bart Van Assche wrote:
> On Wed, 2017-02-01 at 22:01 +, Bart Van Assche wrote:
> > However, a new issue shows up sporadically, an issue that I had not yet seen
> > during any test with a kernel tree from Linus:
> >
> > [ 227.613440] general protection fa
Provide bdi_alloc() forsimple allocation of a BDI that can be used by
filesystems that don't need anything fancy. We use this function when
converting filesystems from embedded struct backing_dev_info into a
dynamically allocated one.
Signed-off-by: Jan Kara
---
include/linux/backing-dev.h | 1
Hello,
this patch series converts all embedded occurences of struct backing_dev_info
to use standalone dynamically allocated structures. This makes bdi handling
unified across all bdi users and generally removes some boilerplate code from
filesystems setting up their own bdi. It also allows us to
Similarly to set_bdev_super() GFS2 just used block device reference to
bdi. Convert it to properly getting bdi reference. The reference will
get automatically dropped on superblock destruction.
CC: Steven Whitehouse
CC: Bob Peterson
CC: cluster-de...@redhat.com
Signed-off-by: Jan Kara
---
fs/g
Allocate struct backing_dev_info separately instead of embedding it
inside client structure. This unifies handling of bdi among users.
CC: Ilya Dryomov
CC: "Yan, Zheng"
CC: Sage Weil
CC: ceph-de...@vger.kernel.org
Signed-off-by: Jan Kara
---
fs/ceph/addr.c| 6 +++---
fs/ceph/debugfs.c |
Allocate struct backing_dev_info separately instead of embedding it
inside the superblock. This unifies handling of bdi among users.
CC: Tyler Hicks
CC: ecryp...@vger.kernel.org
Signed-off-by: Jan Kara
---
fs/ecryptfs/ecryptfs_kernel.h | 1 -
fs/ecryptfs/main.c| 4 +---
2 files chan
It is not used anywhere.
CC: Mike Marshall
Signed-off-by: Jan Kara
---
fs/orangefs/inode.c | 6 --
fs/orangefs/orangefs-kernel.h | 1 -
fs/orangefs/orangefs-mod.c| 12 +---
3 files changed, 1 insertion(+), 18 deletions(-)
diff --git a/fs/orangefs/inode.c b/fs/orange
MTD already allocates backing_dev_info dynamically. Convert it to use
generic infrastructure for this including proper refcounting. We drop
mtd->backing_dev_info as its only use was to pass mtd_bdi pointer from
one file into another and if we wanted to keep that in a clean way, we'd
have to make mt
Allocate struct backing_dev_info separately instead of embedding it
inside superblock. This unifies handling of bdi among users.
CC: Oleg Drokin
CC: Andreas Dilger
CC: James Simmons
CC: lustre-de...@lists.lustre.org
Signed-off-by: Jan Kara
---
.../staging/lustre/lustre/include/lustre_disk.h
Now that all bdi structures filesystems use are properly refcounted, we
can remove the SB_I_DYNBDI flag.
Signed-off-by: Jan Kara
---
drivers/mtd/mtdsuper.c | 1 -
fs/gfs2/ops_fstype.c | 1 -
fs/nfs/super.c | 1 -
fs/nilfs2/super.c | 1 -
fs/super.c | 5 +
include/l
Allocate struct backing_dev_info separately instead of embedding it
inside the superblock. This unifies handling of bdi among users.
CC: Petr Vandrovec
Signed-off-by: Jan Kara
---
fs/ncpfs/inode.c | 8 ++--
fs/ncpfs/ncp_fs_sb.h | 1 -
2 files changed, 2 insertions(+), 7 deletions(-)
di
Allocate struct backing_dev_info separately instead of embedding it
inside the superblock. This unifies handling of bdi among users.
CC: David Howells
CC: linux-...@lists.infradead.org
Signed-off-by: Jan Kara
---
fs/afs/internal.h | 1 -
fs/afs/super.c| 4 +++-
fs/afs/volume.c | 7 ---
Allocate struct backing_dev_info separately instead of embedding it
inside the superblock. This unifies handling of bdi among users.
CC: Jan Harkes
CC: c...@cs.cmu.edu
CC: codal...@coda.cs.cmu.edu
Signed-off-by: Jan Kara
---
fs/coda/inode.c| 11 ---
include/linux/coda_psdev.
Now that all backing_dev_info structure are allocated separately, we can
drop some unused functions.
Signed-off-by: Jan Kara
---
include/linux/backing-dev.h | 5 -
mm/backing-dev.c| 54 +
2 files changed, 5 insertions(+), 54 deletions(
Allocate struct backing_dev_info separately instead of embedding it
inside superblock. This unifies handling of bdi among users.
CC: Steve French
CC: linux-c...@vger.kernel.org
Signed-off-by: Jan Kara
---
fs/cifs/cifs_fs_sb.h | 1 -
fs/cifs/cifsfs.c | 7 ++-
fs/cifs/connect.c| 10
Allocate struct backing_dev_info separately instead of embedding it
inside the superblock. This unifies handling of bdi among users.
CC: Richard Weinberger
CC: Artem Bityutskiy
CC: Adrian Hunter
CC: linux-...@lists.infradead.org
Signed-off-by: Jan Kara
---
fs/ubifs/super.c | 23 +++---
Most users will want to unregister bdi when dropping last reference to a
bdi. Only a few users (like block devices) want to play more complex
tricks with bdi registration and unregistration. So unregister bdi when
the last reference to bdi is dropped and just make sure we don't
unregister the bdi t
Allocate struct backing_dev_info separately instead of embedding it
inside the superblock. This unifies handling of bdi among users.
CC: Miklos Szeredi
CC: linux-fsde...@vger.kernel.org
Signed-off-by: Jan Kara
---
fs/fuse/dev.c| 8
fs/fuse/fuse_i.h | 3 ---
fs/fuse/inode.c | 42
Allocate struct backing_dev_info separately instead of embedding it
inside the superblock. This unifies handling of bdi among users.
CC: Trond Myklebust
CC: Anna Schumaker
CC: linux-...@vger.kernel.org
Signed-off-by: Jan Kara
---
fs/nfs/client.c | 10 --
fs/nfs/internal.h
Similarly to set_bdev_super() NILFS2 just used block device reference to
bdi. Convert it to properly getting bdi reference. The reference will
get automatically dropped on superblock destruction.
CC: Ryusuke Konishi
CC: linux-ni...@vger.kernel.org
Signed-off-by: Jan Kara
---
fs/nilfs2/super.c |
Provide helper functions for setting up dynamically allocated
backing_dev_info structures for filesystems and cleaning them up on
superblock destruction.
CC: linux-...@lists.infradead.org
CC: linux-...@vger.kernel.org
CC: Petr Vandrovec
CC: linux-ni...@vger.kernel.org
CC: cluster-de...@redhat.com
Allocate struct backing_dev_info separately instead of embedding it
inside the superblock. This unifies handling of bdi among users.
CC: Boaz Harrosh
CC: Benny Halevy
CC: osd-...@open-osd.org
Signed-off-by: Jan Kara
---
fs/exofs/exofs.h | 1 -
fs/exofs/super.c | 17 ++---
2 files
Add function that registers bdi and takes va_list instead of variable
number of arguments.
Signed-off-by: Jan Kara
---
include/linux/backing-dev.h | 2 ++
mm/backing-dev.c| 20 +++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/include/linux/backing
So far we just relied on block device to hold a bdi reference for us
while the filesystem is mounted. While that works perfectly fine, it is
a bit awkward that we have a pointer to a refcounted structure in the
superblock without proper reference. So make s_bdi hold a proper
reference to block devi
Allocate struct backing_dev_info separately instead of embedding it
inside superblock. This unifies handling of bdi among users.
CC: Chris Mason
CC: Josef Bacik
CC: David Sterba
CC: linux-bt...@vger.kernel.org
Signed-off-by: Jan Kara
---
fs/btrfs/ctree.h | 1 -
fs/btrfs/disk-io.c | 36
Allocate struct backing_dev_info separately instead of embedding it
inside session. This unifies handling of bdi among users.
CC: Eric Van Hensbergen
CC: Ron Minnich
CC: Latchesar Ionkov
CC: v9fs-develo...@lists.sourceforge.net
Signed-off-by: Jan Kara
---
fs/9p/v9fs.c | 10 +-
fs
On Wed, 2017-02-01 at 22:01 +, Bart Van Assche wrote:
> However, a new issue shows up sporadically, an issue that I had not yet seen
> during any test with a kernel tree from Linus:
>
> [ 227.613440] general protection fault: [#1] SMP
> [ 227.613495] Modules linked in: dm_service_time ib
On 01/31/2017 03:53 PM, Omar Sandoval wrote:
> From: Omar Sandoval
>
> When I moved the blk-mq debugging information to debugfs, I didn't
> realize that blktrace also created directories in debugfs that
> conflicted with the blk-mq directories. This series fixes that.
>
> Patch 1 adds a new debu
On Thu, Feb 02, 2017 at 09:01:45AM -0800, Omar Sandoval wrote:
> On Thu, Feb 02, 2017 at 11:58:53AM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Feb 01, 2017 at 12:31:15AM -0800, Omar Sandoval wrote:
> > > On Wed, Feb 01, 2017 at 09:16:08AM +0100, Greg Kroah-Hartman wrote:
> > > > On Tue, Jan 31, 2
On Thu, Feb 02, 2017 at 08:17:31AM -0700, Jens Axboe wrote:
> On 02/02/2017 03:58 AM, Greg Kroah-Hartman wrote:
> > On Wed, Feb 01, 2017 at 12:31:15AM -0800, Omar Sandoval wrote:
> >> On Wed, Feb 01, 2017 at 09:16:08AM +0100, Greg Kroah-Hartman wrote:
> >>> On Tue, Jan 31, 2017 at 02:53:16PM -0800,
On Thu, Feb 02, 2017 at 11:58:53AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 01, 2017 at 12:31:15AM -0800, Omar Sandoval wrote:
> > On Wed, Feb 01, 2017 at 09:16:08AM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 31, 2017 at 02:53:16PM -0800, Omar Sandoval wrote:
> > > > From: Omar Sandov
If we end up doing a request-to-request merge when we have completed
a bio-to-request merge, we free the request from deep down in that
path. For blk-mq-sched, the merge path has to hold the appropriate
lock, but we don't need it for freeing the request. And in fact
holding the lock is problematic,
I tested the patch I sent to Paolo yesterday, and it seems to work
fine. I broke it up into two pieces, so the functional change is
restricted to patch #2.
Basically this fixes the case where we can invoke the blk-mq-sched
put request functions in an inconsistent state. Most of the time we
invoke
When we attempt to merge request-to-request, we return a 0/1 if we
ended up merging or not. Change that to return the pointer to the
request that we freed. We will use this to move the freeing of
that request out of the merge logic, so that callers can drop
locks before freeing the request.
There
On 02/02/2017 02:19 AM, Paolo Valente wrote:
> The scheme is clear. One comment, in case it could make sense and
> avoid more complexity: since put_rq_priv is invoked in two different
> contexts, process or interrupt, I didn't feel so confusing that, when
> put_rq_priv is invoked in the context wh
On 02/01/2017 03:43 PM, Jens Axboe wrote:
> On 02/01/2017 02:40 PM, Dan Williams wrote:
>> On Wed, Feb 1, 2017 at 2:35 PM, Jens Axboe wrote:
>>> On 02/01/2017 02:05 PM, Dan Williams wrote:
Warnings of the following form occur because scsi reuses a devt number
while the block layer still
On 02/02/2017 03:58 AM, Greg Kroah-Hartman wrote:
> On Wed, Feb 01, 2017 at 12:31:15AM -0800, Omar Sandoval wrote:
>> On Wed, Feb 01, 2017 at 09:16:08AM +0100, Greg Kroah-Hartman wrote:
>>> On Tue, Jan 31, 2017 at 02:53:16PM -0800, Omar Sandoval wrote:
From: Omar Sandoval
When I mov
On 02/02/2017 07:56 AM, Jan Kara wrote:
> Hello,
>
> this is the third version of the patch series that 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
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:
Hello,
this is the third version of the patch series that 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 a
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.
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
blk_get_backing_dev_info() is now a simple dereference. Remove that
function and simplify some code around that.
Signed-off-by: Jan Kara
---
block/blk-core.c| 14 --
block/compat_ioctl.c| 7 ++-
block/ioctl.c | 7 ++-
fs/btrfs/disk-io.c
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.
Reviewed-by: Christoph Hellwig
Signed-off-by: Jan Kara
---
bloc
On Wed 01-02-17 14:45:20, Jens Axboe wrote:
> On 02/01/2017 04:22 AM, Jan Kara wrote:
> > On Wed 01-02-17 01:50:07, Christoph Hellwig wrote:
> >> On Tue, Jan 31, 2017 at 01:54:28PM +0100, Jan Kara wrote:
> >>> Instead of storing backing_dev_info inside struct request_queue,
> >>> allocate it dynami
On Wed, Feb 01, 2017 at 12:31:15AM -0800, Omar Sandoval wrote:
> On Wed, Feb 01, 2017 at 09:16:08AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 31, 2017 at 02:53:16PM -0800, Omar Sandoval wrote:
> > > From: Omar Sandoval
> > >
> > > When I moved the blk-mq debugging information to debugfs, I
Thanks very much Ming and all !
I referred to multipage bvec patches link and it was indeed good & insightful.
I have few more query related to immutable bvecs & multipage bvecs, in
particular related to 4.4 kernel --
1) My understanding is bi_vcnt can't be used for a cloned BIO because
'bio_clo
> Il giorno 02 feb 2017, alle ore 06:19, Jens Axboe ha scritto:
>
> On 02/01/2017 04:11 AM, Paolo Valente wrote:
>>> +static bool dd_bio_merge(struct blk_mq_hw_ctx *hctx, struct bio *bio)
>>> +{
>>> + struct request_queue *q = hctx->queue;
>>> + struct deadline_data *dd = q->elevator->elevat
Looks good,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
70 matches
Mail list logo
