Ming Lei writes:
> Hi Rusty,
Hi Ming!
Sorry, I was on vacation. I'm back and slowly working through
all my mail...
> 1, FIO script
> [global]
> direct=1
> size=128G
> bsrange=${BS}-${BS}
> timeout=60
> numjobs=4
> ioengine=libaio
> iodepth=64
> filename=/dev/vdb #backed by
Ming Lei ming@canonical.com writes:
Hi Rusty,
Hi Ming!
Sorry, I was on vacation. I'm back and slowly working through
all my mail...
1, FIO script
[global]
direct=1
size=128G
bsrange=${BS}-${BS}
timeout=60
numjobs=4
ioengine=libaio
iodepth=64
filename=/dev/vdb
Hi Rusty,
On Fri, Sep 12, 2014 at 9:43 AM, Rusty Russell wrote:
> Ming Lei writes:
>> On Thu, Sep 11, 2014 at 7:38 AM, Rusty Russell wrote:
>>> Rusty Russell writes:
Rusty Russell writes:
Here's what I have. It seems to work as expected, but I haven't
benchmarked it.
>>>
>>>
Hi Rusty,
On Fri, Sep 12, 2014 at 9:43 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Ming Lei ming@canonical.com writes:
On Thu, Sep 11, 2014 at 7:38 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Rusty Russell ru...@rustcorp.com.au writes:
Rusty Russell ru...@rustcorp.com.au writes:
Ming Lei writes:
> On Thu, Sep 11, 2014 at 7:38 AM, Rusty Russell wrote:
>> Rusty Russell writes:
>>> Rusty Russell writes:
>>> Here's what I have. It seems to work as expected, but I haven't
>>> benchmarked it.
>>
>> Hi Ming,
>>
>> Any chance you can run your benchmarks against this
Ming Lei ming@canonical.com writes:
On Thu, Sep 11, 2014 at 7:38 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Rusty Russell ru...@rustcorp.com.au writes:
Rusty Russell ru...@rustcorp.com.au writes:
Here's what I have. It seems to work as expected, but I haven't
benchmarked it.
Hi
On Thu, Sep 11, 2014 at 7:38 AM, Rusty Russell wrote:
> Rusty Russell writes:
>> Rusty Russell writes:
>> Here's what I have. It seems to work as expected, but I haven't
>> benchmarked it.
>
> Hi Ming,
>
> Any chance you can run your benchmarks against this patch?
I can run the
Rusty Russell writes:
> Rusty Russell writes:
> Here's what I have. It seems to work as expected, but I haven't
> benchmarked it.
Hi Ming,
Any chance you can run your benchmarks against this patch?
Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe
Rusty Russell ru...@rustcorp.com.au writes:
Rusty Russell ru...@rustcorp.com.au writes:
Here's what I have. It seems to work as expected, but I haven't
benchmarked it.
Hi Ming,
Any chance you can run your benchmarks against this patch?
Thanks,
Rusty.
--
To unsubscribe from this
On Thu, Sep 11, 2014 at 7:38 AM, Rusty Russell ru...@rustcorp.com.au wrote:
Rusty Russell ru...@rustcorp.com.au writes:
Rusty Russell ru...@rustcorp.com.au writes:
Here's what I have. It seems to work as expected, but I haven't
benchmarked it.
Hi Ming,
Any chance you can run your
Rusty Russell writes:
> Ming Lei writes:
>> On Tue, 02 Sep 2014 10:24:24 -0600
>> Jens Axboe wrote:
>>
>>> On 09/02/2014 10:21 AM, Christoph Hellwig wrote:
>>> > Btw, one thing we should reconsider is where we set
>>> > QUEUE_FLAG_NO_SG_MERGE. At least for virtio-blk it seems to me that
>>> >
On Fri, Sep 5, 2014 at 2:26 PM, Ming Lei wrote:
> On Fri, Sep 5, 2014 at 1:43 PM, Rusty Russell wrote:
>
> The main problem is the extra kmalloc(), which might be
> improved by a memory pool.
Or use kind of EWMA model to cache previous allocated indirect descriptors.
Thanks,
--
To unsubscribe
On Fri, Sep 5, 2014 at 1:43 PM, Rusty Russell wrote:
> Ming Lei writes:
>> On Tue, 02 Sep 2014 10:24:24 -0600
>> Jens Axboe wrote:
>>
>>> On 09/02/2014 10:21 AM, Christoph Hellwig wrote:
>>> > Btw, one thing we should reconsider is where we set
>>> > QUEUE_FLAG_NO_SG_MERGE. At least for
On Fri, Sep 5, 2014 at 1:43 PM, Rusty Russell ru...@rustcorp.com.au wrote:
Ming Lei ming@canonical.com writes:
On Tue, 02 Sep 2014 10:24:24 -0600
Jens Axboe ax...@kernel.dk wrote:
On 09/02/2014 10:21 AM, Christoph Hellwig wrote:
Btw, one thing we should reconsider is where we set
On Fri, Sep 5, 2014 at 2:26 PM, Ming Lei ming@canonical.com wrote:
On Fri, Sep 5, 2014 at 1:43 PM, Rusty Russell ru...@rustcorp.com.au wrote:
The main problem is the extra kmalloc(), which might be
improved by a memory pool.
Or use kind of EWMA model to cache previous allocated indirect
Rusty Russell ru...@rustcorp.com.au writes:
Ming Lei ming@canonical.com writes:
On Tue, 02 Sep 2014 10:24:24 -0600
Jens Axboe ax...@kernel.dk wrote:
On 09/02/2014 10:21 AM, Christoph Hellwig wrote:
Btw, one thing we should reconsider is where we set
QUEUE_FLAG_NO_SG_MERGE. At least
Ming Lei writes:
> On Tue, 02 Sep 2014 10:24:24 -0600
> Jens Axboe wrote:
>
>> On 09/02/2014 10:21 AM, Christoph Hellwig wrote:
>> > Btw, one thing we should reconsider is where we set
>> > QUEUE_FLAG_NO_SG_MERGE. At least for virtio-blk it seems to me that
>> > doing the S/G merge should be a
Ming Lei ming@canonical.com writes:
On Tue, 02 Sep 2014 10:24:24 -0600
Jens Axboe ax...@kernel.dk wrote:
On 09/02/2014 10:21 AM, Christoph Hellwig wrote:
Btw, one thing we should reconsider is where we set
QUEUE_FLAG_NO_SG_MERGE. At least for virtio-blk it seems to me that
doing the
On Wed, Sep 3, 2014 at 1:01 AM, Jeff Moyer wrote:
> Jens Axboe writes:
>
>> On 09/02/2014 09:02 AM, Ming Lei wrote:
>>> QUEUE_FLAG_NO_SG_MERGE is set at default for blk-mq devices,
>>> so bio->bi_phys_segment computed may be bigger than
>>> queue_max_segments(q) for blk-mq devices, then drivers
On Wed, Sep 3, 2014 at 12:19 PM, Ming Lei wrote:
> On Tue, 02 Sep 2014 10:24:24 -0600
> Jens Axboe wrote:
>
>> On 09/02/2014 10:21 AM, Christoph Hellwig wrote:
>> > Btw, one thing we should reconsider is where we set
>> > QUEUE_FLAG_NO_SG_MERGE. At least for virtio-blk it seems to me that
>> >
On Wed, Sep 3, 2014 at 12:19 PM, Ming Lei ming@canonical.com wrote:
On Tue, 02 Sep 2014 10:24:24 -0600
Jens Axboe ax...@kernel.dk wrote:
On 09/02/2014 10:21 AM, Christoph Hellwig wrote:
Btw, one thing we should reconsider is where we set
QUEUE_FLAG_NO_SG_MERGE. At least for virtio-blk
On Wed, Sep 3, 2014 at 1:01 AM, Jeff Moyer jmo...@redhat.com wrote:
Jens Axboe ax...@kernel.dk writes:
On 09/02/2014 09:02 AM, Ming Lei wrote:
QUEUE_FLAG_NO_SG_MERGE is set at default for blk-mq devices,
so bio-bi_phys_segment computed may be bigger than
queue_max_segments(q) for blk-mq
On Tue, 02 Sep 2014 10:24:24 -0600
Jens Axboe wrote:
> On 09/02/2014 10:21 AM, Christoph Hellwig wrote:
> > Btw, one thing we should reconsider is where we set
> > QUEUE_FLAG_NO_SG_MERGE. At least for virtio-blk it seems to me that
> > doing the S/G merge should be a lot cheaper than fanning
Jens Axboe writes:
> On 09/02/2014 09:02 AM, Ming Lei wrote:
>> QUEUE_FLAG_NO_SG_MERGE is set at default for blk-mq devices,
>> so bio->bi_phys_segment computed may be bigger than
>> queue_max_segments(q) for blk-mq devices, then drivers will
>> fail to handle the case, for example, BUG_ON() in
On 09/02/2014 10:21 AM, Christoph Hellwig wrote:
> Btw, one thing we should reconsider is where we set
> QUEUE_FLAG_NO_SG_MERGE. At least for virtio-blk it seems to me that
> doing the S/G merge should be a lot cheaper than fanning out into the
> indirect descriptors.
And we might consider
On 09/02/2014 09:02 AM, Ming Lei wrote:
> QUEUE_FLAG_NO_SG_MERGE is set at default for blk-mq devices,
> so bio->bi_phys_segment computed may be bigger than
> queue_max_segments(q) for blk-mq devices, then drivers will
> fail to handle the case, for example, BUG_ON() in
> virtio_queue_rq() can be
Btw, one thing we should reconsider is where we set
QUEUE_FLAG_NO_SG_MERGE. At least for virtio-blk it seems to me that
doing the S/G merge should be a lot cheaper than fanning out into the
indirect descriptors.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
QUEUE_FLAG_NO_SG_MERGE is set at default for blk-mq devices,
so bio->bi_phys_segment computed may be bigger than
queue_max_segments(q) for blk-mq devices, then drivers will
fail to handle the case, for example, BUG_ON() in
virtio_queue_rq() can be triggerd for virtio-blk:
QUEUE_FLAG_NO_SG_MERGE is set at default for blk-mq devices,
so bio-bi_phys_segment computed may be bigger than
queue_max_segments(q) for blk-mq devices, then drivers will
fail to handle the case, for example, BUG_ON() in
virtio_queue_rq() can be triggerd for virtio-blk:
Btw, one thing we should reconsider is where we set
QUEUE_FLAG_NO_SG_MERGE. At least for virtio-blk it seems to me that
doing the S/G merge should be a lot cheaper than fanning out into the
indirect descriptors.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On 09/02/2014 09:02 AM, Ming Lei wrote:
QUEUE_FLAG_NO_SG_MERGE is set at default for blk-mq devices,
so bio-bi_phys_segment computed may be bigger than
queue_max_segments(q) for blk-mq devices, then drivers will
fail to handle the case, for example, BUG_ON() in
virtio_queue_rq() can be
On 09/02/2014 10:21 AM, Christoph Hellwig wrote:
Btw, one thing we should reconsider is where we set
QUEUE_FLAG_NO_SG_MERGE. At least for virtio-blk it seems to me that
doing the S/G merge should be a lot cheaper than fanning out into the
indirect descriptors.
And we might consider flipping
Jens Axboe ax...@kernel.dk writes:
On 09/02/2014 09:02 AM, Ming Lei wrote:
QUEUE_FLAG_NO_SG_MERGE is set at default for blk-mq devices,
so bio-bi_phys_segment computed may be bigger than
queue_max_segments(q) for blk-mq devices, then drivers will
fail to handle the case, for example,
On Tue, 02 Sep 2014 10:24:24 -0600
Jens Axboe ax...@kernel.dk wrote:
On 09/02/2014 10:21 AM, Christoph Hellwig wrote:
Btw, one thing we should reconsider is where we set
QUEUE_FLAG_NO_SG_MERGE. At least for virtio-blk it seems to me that
doing the S/G merge should be a lot cheaper than
34 matches
Mail list logo
