e opportunities for max() and min() were utilized to address
>> the warnings.
>
> Please split this into 3 patches, one for each component.
Don't bother with the io_uring one, code is far more readable as-is.
--
Jens Axboe
___
Virt
or commands and structs, and it should be possible to
just setup a struct io_wq and use that.
Obviously might need a bit of refactoring work and exporting of symbols,
io_uring is y/n so we don't export anything. But I think it should all
be minor work, really.
--
Jens Axboe
_
LES, and get rid of the whole ".no_files" thing. Again, if
> vhost doesn't use any files, it shouldn't matter, and looking
> different just to be different is wrong. But if vhost doesn't use any
> files, the current situation shouldn't be a bug either.
Only potent
911af9fbaff299d8e9e45
Best regards,
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
't blk_mq_end_request_batch(iob) take care of this for us?
> Why does it set the state to IDLE instead of COMPLETE?
>
> I think Jens can confirm whether we really want all drivers that use
> polling and io_comp_batch to manually call
> blk_mq_set_request_complete().
Should not be a
On 12/5/22 1:29?PM, Michael S. Tsirkin wrote:
> On Mon, Dec 05, 2022 at 11:53:51AM -0700, Jens Axboe wrote:
>> On 12/5/22 11:36?AM, Alvaro Karsz wrote:
>>> Hi,
>>>
>>>> Is this based on some spec? Because it looks pretty odd to me. There
>>>> can
> for generic devices these days, if any.
>
> Yes, this is based on the virtio spec
> https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html
> section 5.2.6
And where did this come from?
--
Jens Axboe
___
Virtual
ation by sending a VIRTIO_BLK_T_GET_LIFETIME command to the device.
s/VBLK_LIFETIME/VBLK_GET_LIFETIME
for the above.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
ks pretty odd to me. There
can be a pretty wide range of two/three/etc level cells with wildly
different ranges of durability. And there's really not a lot of slc
for generic devices these days, if any.
--
Jens Axboe
___
Virtualization mailing list
hanks!
[1/1] virtio-blk: replace ida_simple[get|remove] with ida_[alloc_range|free]
commit: 92a34c461719eb4a3f95353bb7b27a3238eb7478
Best regards,
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://l
#x27;t see them,
or only see small parts of a patchset. And it's really annoying to have
to deal with as a recipient.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
ks!
[1/1] blk-mq: avoid double ->queue_rq() because of early timeout
commit: 82c229476b8f6afd7e09bc4dc77d89dc19ff7688
Best regards,
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 10/25/22 6:21 PM, Ming Lei wrote:
> On Tue, Oct 25, 2022 at 12:11:39PM -0600, Jens Axboe wrote:
>> On 10/24/22 6:55 PM, Ming Lei wrote:
>>> @@ -1593,10 +1598,18 @@ static void blk_mq_timeout_work(struct work_struct
>>> *work)
>>> if (!p
; + blk_mq_wait_quiesce_done(q);
I'm a little worried about this bit - so we'll basically do a sync RCU
every time the timeout timer runs... Depending on machine load, that
can take a long time.
--
Jens Axboe
___
Virtualization
e, and also dropping the inline as the compiler
will work that out anyway.
Apart from that minor nit, looks good to me.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
e1be8f876f320a0972a715daec0a50
[10/11] rnbd-srv: use bdev_discard_alignment
commit: 18292faa89d2bff3bdd33ab9c065f45fb6710e47
[11/11] xen-blkback: use bdev_discard_alignment
commit: c899b23533866910c90ef4386b501af50270d320
Best regards,
--
Jens Axboe
___
Virtualization mailin
ranularity helper
commit: 7b47ef52d0a2025fd1408a8a0990933b8e1e510f
[26/27] block: decouple REQ_OP_SECURE_ERASE from REQ_OP_DISCARD
commit: 44abff2c0b970ae3d310b97617525dc01f248d7c
[27/27] direct-io: remove random prefetches
commit: c22198e78d523c8fa079bbb70b2523bb6aa518
itcall_debug log.
>
> Give each of these init and exit functions unique driver-specific
> names to eliminate the anonymous names.
>
> [...]
Applied, thanks!
[1/9] virtio_blk: eliminate anonymous module_init & module_exit
commit: bcfe9b6cbb4438b8c1c
9cd3cab2dde
[5/5] virtio_blk: simplify refcounting
commit: 24b45e6c25173abcf8d5e82285212b47f2b0f86b
Best regards,
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 11/22/21 3:02 AM, Christian Brauner wrote:
> On Sun, Nov 21, 2021 at 11:17:11AM -0700, Jens Axboe wrote:
>> On 11/21/21 10:49 AM, Mike Christie wrote:
>>> Convert io_uring and io-wq to use kernel_worker.
>>
>> I don't like the kernel_worker name, that implies
sk that just happens to never
exit to userspace.
Can we do a better name? At least io_thread doesn't imply that.
Also I do think this deserves a bit more commit message, there's really
nothing in here.
--
Jens Axboe
___
Virtualization mailin
7d9a8606490aaa1b805bafe6c37e1
Best regards,
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 10/4/21 1:21 PM, Mike Christie wrote:
> Convert io_uring and io-wq to use kernel_worker.
Looks good to me:
Reviewed-by: Jens Axboe
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
ht
> node);
Looks like an extra 'i' snuck in here, causing unrelated changes.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
; KERN_WORKER_NO_SIGS)
> + ignore_signals(tsk);
> +
> + return tsk;
When I originally did it this way, Eric (correctly) pointed out that
it's racy. See where it's currently done as part of copy_process(), not
after.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 9/1/21 4:25 PM, Max Gurtovoy wrote:
>
> On 9/1/2021 6:27 PM, Jens Axboe wrote:
>> On 9/1/21 8:58 AM, Max Gurtovoy wrote:
>>> On 9/1/2021 5:50 PM, Michael S. Tsirkin wrote:
>>>> On Wed, Sep 01, 2021 at 04:14:34PM +0300, Max Gurtovoy wrote:
>>>>>
here could be
performance implications associated with that. Which would be
particularly evident with 1 segment requests, as the results would seem
to indicate as well.
Probably needs better testing. A profile of a peak run before and after
and a diff of the two might also be interesting.
The c
ontroller or in an architecture specific driver where highmem is
> impossible.
Applied, thanks.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
gt; in all drivers that do not have any caveats in their gendisk and
> request_queue lifetime rules.
Applied, thanks.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
sistency
> and clarity of the code.
>
> If you do go ahead, please update the blk_get_request() doc comment
> explicitly mentioning that blk_mq_free_request() needs to be called.
Would make sense to rename blk_get_request() to blk_mq_alloc_request()
and then we have A
uld be sufficient?
>>>
>> Actually I mean the deadlock described in commit f0b493e ("io_uring:
>> prevent potential eventfd recursion on poll"). It can break this bug
>> fix if we just increase EVENTFD_WAKEUP_DEPTH.
>
>
> Ok, so can wait do something s
xecute_rq_nowait and blk_execute_rq.
> Also update the comment for blk_execute_rq_nowait.
>
Applied, thanks.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
t's this against? The lightnvm patch doesn't apply.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
f ->revalidate_disk entirely, but ther are a lot
> more patches needed for that.
Applied, thanks.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 8/20/20 7:19 PM, Tian Tao wrote:
> Use kobj_to_dev() instead of container_of()
Applied, thanks.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listi
On 6/14/20 10:14 PM, Hou Tao wrote:
> Else there will be memory leak if alloc_disk() fails.
Applied, thanks.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listi
a few patches
> - fix a comment typo
> - cover the newly merged use_mm/unuse_mm caller in vfio
You can add my reviewed-by/tested-by to the patches, passes the
io_uring regression tests.
--
Jens Axboe
___
Virtualization mailing list
Virtualizat
peaking as
> the person who had that idea back in the day).
We had this very discussion two years ago, and we never got it removed.
Let's please get it done.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.
into MSI-X with one vector for config
> and one shared for queues.
>
> Considering above reasons, this patch set limits the number of hw queues
> used by nr_cpu_ids for both virtio-blk and virtio-scsi.
I picked both up for 5.1.
--
Jens Axboe
___
On 3/11/19 7:31 PM, Dongli Zhang wrote:
> Use HCTX_TYPE_DEFAULT instead of 0 to avoid hardcoding.
Applied, thanks.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mail
rstanding how to set up a
> target platform.
>
> Changes from v1:
> - Fixed bugs pointed out by Jens in iscsit_wait_for_tag()
> - Abstracted out tag freeing as requested by Bart
> - Made iscsit_wait_for_tag static as pointed out by 0da
On 5/15/18 10:11 AM, Jens Axboe wrote:
> On 5/15/18 10:00 AM, Matthew Wilcox wrote:
>> From: Matthew Wilcox
>>
>> The sbitmap and the percpu_ida perform essentially the same task,
>> allocating tags for commands. Since the sbitmap is more used than
>> the percpu_
On 5/24/18 7:01 AM, Joe Perches wrote:
> On Thu, 2018-05-24 at 06:47 -0600, Jens Axboe wrote:
>> On 5/23/18 4:35 PM, Joe Perches wrote:
>>> On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote:
>>>> On 5/23/18 2:05 PM, Joe Perches wrote:
>>>>> Conve
On 5/23/18 4:35 PM, Joe Perches wrote:
> On Wed, 2018-05-23 at 15:27 -0600, Jens Axboe wrote:
>> On 5/23/18 2:05 PM, Joe Perches wrote:
>>> Convert the S_ symbolic permissions to their octal equivalents as
>>> using octal and not symbolic permissions is preferred b
on via:
> $ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplace
>
> Miscellanea:
>
> o Wrapped modified multi-line calls to a single line where appropriate
> o Realign modified multi-line calls to open parenthesis
Honestly, I see this as
On 5/15/18 10:11 AM, Jens Axboe wrote:
> On 5/15/18 10:00 AM, Matthew Wilcox wrote:
>> From: Matthew Wilcox
>>
>> The sbitmap and the percpu_ida perform essentially the same task,
>> allocating tags for commands. Since the sbitmap is more used than
>> the percpu_
g = iscsit_wait_for_tag(se_sess, state, &cpu);
> if (tag < 0)
> return NULL;
Might make sense to just roll the whole thing into iscsi_get_tag(), that
would be cleaner.
sbitmap should provide a helper for that, but we can do that cleanup
later. That would encapsulate things like the per-cpu caching hint too,
for instance.
Rest looks fine to me.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
rs() to set the limit,
and then the soft limit can be modified by a udev rule. Technically the
driver doesn't own the software limit, it's imposed to ensure that we
don't introduce too much latency per request.
Your situation is no different from many other setups, where
heard otherwise. I'll just pop it
off, for-linus isn't a stable branch.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 11/21/2017 01:31 PM, Christian Borntraeger wrote:
>
>
> On 11/21/2017 09:21 PM, Jens Axboe wrote:
>> On 11/21/2017 01:19 PM, Christian Borntraeger wrote:
>>>
>>> On 11/21/2017 09:14 PM, Jens Axboe wrote:
>>>> On 11/21/2017 01:12 PM, Christian Bornt
On 11/21/2017 01:19 PM, Christian Borntraeger wrote:
>
> On 11/21/2017 09:14 PM, Jens Axboe wrote:
>> On 11/21/2017 01:12 PM, Christian Borntraeger wrote:
>>>
>>>
>>> On 11/21/2017 08:30 PM, Jens Axboe wrote:
>>>> On 11/21/2017 12:15 PM, Chri
On 11/21/2017 01:12 PM, Christian Borntraeger wrote:
>
>
> On 11/21/2017 08:30 PM, Jens Axboe wrote:
>> On 11/21/2017 12:15 PM, Christian Borntraeger wrote:
>>>
>>>
>>> On 11/21/2017 07:39 PM, Jens Axboe wrote:
>>>> On 11/21/2017 11
On 11/21/2017 12:15 PM, Christian Borntraeger wrote:
>
>
> On 11/21/2017 07:39 PM, Jens Axboe wrote:
>> On 11/21/2017 11:27 AM, Jens Axboe wrote:
>>> On 11/21/2017 11:12 AM, Christian Borntraeger wrote:
>>>>
>>>>
>>>> On 11/21/2017 07
On 11/21/2017 11:27 AM, Jens Axboe wrote:
> On 11/21/2017 11:12 AM, Christian Borntraeger wrote:
>>
>>
>> On 11/21/2017 07:09 PM, Jens Axboe wrote:
>>> On 11/21/2017 10:27 AM, Jens Axboe wrote:
>>>> On 11/21/2017 03:14 AM, Christian
On 11/21/2017 11:12 AM, Christian Borntraeger wrote:
>
>
> On 11/21/2017 07:09 PM, Jens Axboe wrote:
>> On 11/21/2017 10:27 AM, Jens Axboe wrote:
>>> On 11/21/2017 03:14 AM, Christian Borntraeger wrote:
>>>> Bisect points to
>>>>
>>>&g
On 11/21/2017 10:27 AM, Jens Axboe wrote:
> On 11/21/2017 03:14 AM, Christian Borntraeger wrote:
>> Bisect points to
>>
>> 1b5a7455d345b223d3a4658a9e5fce985b7998c1 is the first bad commit
>> commit 1b5a7455d345b223d3a4658a9e5fce985b7998c1
>> Author: Christoph Hel
one for each present CPU to avoid this and dramatically simplify
> the code.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Jens Axboe
> Cc: Keith Busch
> Cc: linux-bl...@vger.kernel.org
> Cc: linux-n...@lists.infradead.org
>
On 11/20/2017 01:49 PM, Christian Borntraeger wrote:
>
>
> On 11/20/2017 08:42 PM, Jens Axboe wrote:
>> On 11/20/2017 12:29 PM, Christian Borntraeger wrote:
>>>
>>>
>>> On 11/20/2017 08:20 PM, Bart Van Assche wrote:
>>>> On Fri, 2017-11-17 a
On 11/20/2017 12:29 PM, Christian Borntraeger wrote:
>
>
> On 11/20/2017 08:20 PM, Bart Van Assche wrote:
>> On Fri, 2017-11-17 at 15:42 +0100, Christian Borntraeger wrote:
>>> This is
>>>
>>> b7a71e66d (Jens Axboe2017-08-01 09:28:
quest and the
> SCSI passthrough ioctls optional. It is now only enabled by drivers that
> need it.
>
> In addition I've made SCSI passthrough support in the virtio_blk driver an
> optional compile time feature, as it's not actually needed for m
well, since
> you have one virtio-blk patch already?
No problem, in fact I already queued it up.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 01/09/2017 06:35 AM, Christoph Hellwig wrote:
> Is someone going to pick the patch up and send it to Linus? I keep
> running into all kinds of boot failures whenever I forget to cherry
> pick it into my development trees..
I'll add it.
87 b0 00 00 00 41 83 e6 ef 4a 8b
RIP [] virtio_queue_rq+0x210/0x2b0
RSP:
---[ end trace 8078357c459d5fc0 ]---
So this BUG_ON is from 1cf7e9c68fe84248174e998922b39e508375e7c1.
commit 1cf7e9c68fe84248174e998922b39e508375e7c1
Author: Jens Axboe
Date: Fri Nov 1 10:52:5
On 11/11/2014 09:42 AM, Ming Lei wrote:
> The attached patch should fix the problem, and hope it is the last one, :-)
Dongsu and Jeff, any of you test this variant? I think this is the last
one, at least I hope so as well...
--
Jens Ax
id, Ming is looking into it.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
2.887706] ---[ end trace e667b0f035973c7a ]---
[2.888781] Kernel panic - not syncing: Fatal exception
[2.889765] Kernel Offset: 0x0 from 0x8100 (relocation range:
0x8000-0x9fff)
--
Jens Axboe
___
Virtua
te commits without having to rewrite history...
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
itialization from __blk_mq_alloc_request().
And then we come full circle, that's how the code originally started out
(and it is the saner way to do things). So yes, I'd greatly applaud that.
--
Jens Axboe
___
Virtualization mailing l
{
if (set->ops->init_request(set->driver_data,
tags->rqs[i], hctx_idx, i,
Another way would be to ensure that the timeout handler doesn't touch
hw_ctx or tag_sets that aren't fully initialized yet. But I think this
is sa
- add '__u8 unused' for pending as suggested by Rusty
- use virtio_cread_feature() directly, suggested by Rusty
Sorry, please add Jens' reviewed-by.
Reviewed-by: Jens Axboe
I appreciate very much that one of you may queue these two
patches into your tree so that userspace work
s_notify_dirent_safe under spinlock
> -> calls kernfs_notify which takes a mutex.
>
> So I am guessing it is this commit:
>
> commit d911d98748018f7c8facc035ba39c30f5cce6f9c
> Author: Tejun Heo
> Date: Wed Apr 9 11:07:31 2014 -0400
>
> kernfs: mak
ven't run your patches yet, but from looking at the code, it looks
good. It's pretty straightforward. See feel free to add my reviewed-by.
Rusty, do you want to ack this (and I'll slurp it up for 3.17) or take
this yourself? Or something else?
--
Jens Axboe
_
thout mutli-vq feature
> -- jobs=2, thoughput: 186K iops
> -- jobs=4, thoughput: 199K iops
Awesome! I was hoping someone would do that, and make virtio-blk take
full advantage of blk-mq.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 2014-06-01 19:23, Rusty Russell wrote:
Jens Axboe writes:
On 2014-05-30 00:10, Rusty Russell wrote:
Jens Axboe writes:
If Rusty agrees, I'd like to add it for 3.16 with a stable marker.
Really stable? It improves performance, which is nice. But every patch
which goes into the k
On 2014-05-30 00:10, Rusty Russell wrote:
Jens Axboe writes:
If Rusty agrees, I'd like to add it for 3.16 with a stable marker.
Really stable? It improves performance, which is nice. But every patch
which goes into the kernel fixes a bug, improves clarity, improves
performance or a
On 2014-05-29 21:34, Ming Lei wrote:
On Fri, May 30, 2014 at 11:19 AM, Jens Axboe wrote:
On 2014-05-29 20:49, Ming Lei wrote:
Firstly, it isn't necessary to hold lock of vblk->vq_lock
when notifying hypervisor about queued I/O.
Secondly, virtqueue_notify() will cause world switch an
but it
definitely makes sense and I can see it hurting in other places.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 11/06/2013 05:53 AM, Fengguang Wu wrote:
> Hi Jens,
>
> On Mon, Nov 04, 2013 at 03:58:41PM -0700, Jens Axboe wrote:
>> On 11/04/2013 07:10 AM, Fengguang Wu wrote:
>>> Hi Jens,
>>>
>>> I'm not very sure about this bisect, but anyway it'd be go
On 11/04/2013 07:10 AM, Fengguang Wu wrote:
> Hi Jens,
>
> I'm not very sure about this bisect, but anyway it'd be good to inform
> you of a possible problem on commit
>
> commit 3a02db083a78c9f3c9b69305ab513f9422d91b08
> Author: Jens Axboe
> Date
th your workaround, but if other subsystems have
> the same problem we do, perhaps we should consider a broader solution?
Do other use cases actually exist? I don't think I've come across this
requirement before, since it was introduced (6 years ago, from a cursory
look at th
On Thu, Feb 07 2013, Paolo Bonzini wrote:
> This is useful in places that recycle the same scatterlist multiple
> times, and do not want to incur the cost of sg_init_table every
> time in hot paths.
Looks fine to me.
Acked-by: Jens Axboe
--
J
nks!
Pickedup, thanks for getting that done!
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 06/14/2012 12:02 PM, Fengguang Wu wrote:
> On Thu, Jun 14, 2012 at 11:05:33AM +0200, Jens Axboe wrote:
>> On 06/14/2012 11:01 AM, Fengguang Wu wrote:
>>> Hi Jens,
>>>
>>> On Thu, Jun 14, 2012 at 08:30:11AM +0200, Jens Axboe wrote:
>>>> On
On 06/14/2012 11:01 AM, Fengguang Wu wrote:
> Hi Jens,
>
> On Thu, Jun 14, 2012 at 08:30:11AM +0200, Jens Axboe wrote:
>> On 06/14/2012 01:03 AM, w...@linux.intel.com wrote:
>>> FYI, kernel build failed on
>>>
>>> tree: git://git.kernel.org/pub/
ely code we don't want to have
duplicated. We've had mapping bugs in the past.
Asias, this should be trivial to do, except that blk_rq_map_sg()
potentially maps across bio's as well. The tracking of the prev bio_vec
does not care about cross bio boundaries.
--
Jens Axboe
___
1/3] multiqueue: a hodge
> podge of things
The multiqueue branch is a private branch, it's known broken on many
configs at the moment.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.l
t I thought.
>
> How about placing the "sd_format_disk_name()"
> as "disk_name_format()" into "block/genhd.c"
> ("include/linux/genhd.h")?
Yes, that sounds like the appropriate solution (and name, and where to
put it).
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
fter free
>
> Works fine for me.
>
> Jens, could you merge this for 3.2?
> That is, unless Rusty complains shortly ...
Yep, tentatively added.
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On 2011-04-06 03:32, Rusty Russell wrote:
> On Tue, 05 Apr 2011 07:08:12 +0200, Jens Axboe wrote:
>> On 2011-04-05 06:49, Takuma Umeya wrote:
>>> When virtio block device is removed, index does not get decremented. When
>>> another virtio disk is attached it uses th
roy(vblk->pool);
> vdev->config->del_vqs(vdev);
> kfree(vblk);
> + index--;
> }
>
> static const struct virtio_device_id id_table[] = {
What happens when you delete a device that isn't the last one?
--
Jens Axboe
___
lts when they are in.
I'm very interested as well, I have been hoping for some more adoption
of this. I have mptsas and mpt2sas patches pending as well.
I have not done enough and fully exhaustive weight analysis, so note me
down for wanting such an analysis on
ch an API years ago, so CC'ing the
> usual I/O suspects...
It would be nice to have a more fuller API for this, but the reality is
that only the flush approach is really workable. Even just strict
ordering of requests could only be supported on SCSI,
go away.
> >
> > This is not strictly a regression, given that the problem was introduced
> > in 2.6.31, but I think it should still be fixed for 2.6.32.
>
> It was resubmitted last Friday:
> http://lkml.org/lkml/2009/10/23/196
>
> And is queued in Jens' '
On Thu, May 21 2009, Jeremy Fitzhardinge wrote:
> Roel Kluin wrote:
>> Do not go beyond ARRAY_SIZE of info->shadow
>>
>> Signed-off-by: Roel Kluin
>>
> Acked-by: Jeremy Fitzhardinge
>
> Jens, can you put this into a next-merge-window
n't have an issue
> with large numbers of sectors. The block layer may well...
We should probably just truncate insanely large values like -1 to
something sane. For the above case we already do trunc it to 1MB, as
it's the soft IO size. The segment size is already in bytes, so in fact
e
On Wed, Nov 19 2008, Divyesh Shah wrote:
> On Wed, Nov 19, 2008 at 6:24 AM, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > On Tue, Nov 18 2008, Nauman Rafique wrote:
> >> On Tue, Nov 18, 2008 at 11:12 AM, Jens Axboe <[EMAIL PROTECTED]> wrote:
> >> >
On Tue, Nov 18 2008, Fabio Checconi wrote:
> > From: Jens Axboe <[EMAIL PROTECTED]>
> > Date: Tue, Nov 18, 2008 08:12:08PM +0100
> >
> > On Tue, Nov 18 2008, Fabio Checconi wrote:
> > > BFQ started from CFQ, extending it in the way you correctly describe,
>
On Tue, Nov 18 2008, Nauman Rafique wrote:
> On Tue, Nov 18, 2008 at 11:12 AM, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > On Tue, Nov 18 2008, Fabio Checconi wrote:
> >> > From: Vivek Goyal <[EMAIL PROTECTED]>
> >> > Date: Tue, Nov 18, 2008 09:07:51AM -
viable
alternative.
My main goal here is basically avoiding addition of Yet Another IO
scheduler, especially one that is so closely tied to CFQ already.
I'll start things off by splitting cfq into a few files similar to what
bfq has done, as I think it makes a lot of sense. Fabio, if you c
t;queue);
did test_bit(QUEUE_FLAG_CLUSTER, &vblk->disk->queue->queue_flags) really
return 0 before?
--
Jens Axboe
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
1 - 100 of 122 matches
Mail list logo
