te commits without having to rewrite history...
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
t
{
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 safe
On Thu, May 30 2013, Rusty Russell wrote:
> Jens Axboe writes:
> > On Wed, Feb 27 2013, Rusty Russell wrote:
> >> Aurelien Jarno writes:
> >> > Hi,
> >> >
> >> > I have noticed that virtio-rng only returns zero for kernels >= 2.6.33
>
nsigned int buflen)
> {
> +#ifdef CONFIG_DEBUG_SG
> + BUG_ON(!virt_addr_valid(buf));
> +#endif
> sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
> }
Looks good to me, in lieu of being able to return an error. Want me to
queue it up?
--
Jens Axboe
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 the
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
--
Jens Axboe
--
To unsubscribe from this l
nks!
Pickedup, thanks for getting that done!
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
--
To uns
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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
>bd_inode size.
>
> Call revalidate_disk() which should take care of it. I tested growing disk
> size of already open disk and it works for me.
Thanks, obviously right. Applied.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a mess
ave to bring the lock back.
That's not going to happen, having that lock in there was a disaster for
small IO on fast devices. It's essentially the limiting factor on
benchmark runs on the RHEL kernels that have it included and enabled...
--
Jens Axboe
--
To unsubscribe from this l
may be there is a safer version of pcpu alloc which will return
> without allocation if pcpu_alloc_mutex is already locked.
Both of these proposed solutions aren't really pretty. It would be
cleaner and have better runtime for the fast path if you could alloc all
of these when the non-roo
>
> GFP_FS simply marks the beginning of a nested, unrelated context that
> uses the same thread, just like an interrupt. Kudos to lockdep for
> catching that.
>
> I think the allocation in blkio_alloc_blkg_stats() should be moved out
> of the I/O path into some init funct
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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
: [PATCH 1/1] [virt] virtio-blk: Use ida to allocate disk index
>>>
>>> Current index allocation in virtio-blk is based on a monotonically
>>> increasing variable "index". It could cause some confusion about disk
>>> name in the case of hot-plugging disks.
are). So it could be
that virtio_blk is just doing things rather suboptimally in some places,
and that it would be possible to claim most of that speedup there too.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kern
r 3.1 with your ack. Thanks
Johannes.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 virtio_blk as well.
--
Jens Axb
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, and even there the
kernel still lacks p
er the driver (except for structure size)
> makes no interpretation of the data. The structure
> data is copied wholesale to userspace via a
> HDIO_GET_IDENTITY ioctl command (eg: hdparm -i ).
Added!
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe kvm&
; > + err = virtio_config_buf(vblk->vdev, VIRTIO_BLK_F_IDENTIFY,
> > + offsetof(struct virtio_blk_config, identify), id,
> > + VIRTIO_BLK_ID_BYTES);
>
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Dec 12 2008, Andrea Arcangeli wrote:
> On Fri, Dec 12, 2008 at 09:23:10AM +0100, Jens Axboe wrote:
> > aio is only async with O_DIRECT, with buffered IO it's sync.
>
> That's very bad, because aio is as needed for O_DIRECT as for buffered
> read seeking worklo
ing sync-reads kernel aio pays off as well as with O_DIRECT.
aio is only async with O_DIRECT, with buffered IO it's sync.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 29 2008, Christian Borntraeger wrote:
> Am Donnerstag, 29. Mai 2008 schrieb Jens Axboe:
> > > > Just that u64 seems like overkill: u32?
> > >
> > > Definitely, u32 would be just fine, u64 is way overkill :-)
> >
> > Even u16 would w
On Thu, May 29 2008, Jens Axboe wrote:
> On Thu, May 29 2008, Rusty Russell wrote:
> > On Tuesday 27 May 2008 19:04:59 Christian Borntraeger wrote:
> > > Rusty, Jens,
> > >
> > > I need your opinion on the following patch. It seems to work, but I would
> >
:
>
> Looks like the right approach to me. Don't know about the block side
> of it...
Looks good to me, definitely an improvement for eg loop backed
storage.
> Just that u64 seems like overkill: u32?
Definitely, u32 would be just fine, u64 is way overkill :-)
--
Jens Axboe
--
On Thu, May 22 2008, Chris Lalancette wrote:
> Jens Axboe wrote:
> > On Thu, May 22 2008, Rusty Russell wrote:
> >> On Wednesday 21 May 2008 23:12:39 Chris Lalancette wrote:
> >>> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> >>>
up_queue() *after* del_gendisk: does it matter?
>
> Jens CC'd: he's gentle with my dumb questions... Rusty.
del_gendisk() can generate IO, so it would seem safer to do that
_before_ putting the queue reference :-)
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
29 matches
Mail list logo
