On 12/7/22 5:35?PM, Keith Busch wrote:
> On Wed, Dec 07, 2022 at 11:17:12PM +, Chaitanya Kulkarni wrote:
>> On 12/7/22 15:08, Jens Axboe wrote:
>>>
>>> My default peak testing runs at 122M IOPS. That's also the peak IOPS of
>>> the devices combined, and with iostats disabled. If I enabled
On Wed, Dec 07, 2022 at 10:32:04PM +, Gulam Mohamed wrote:
> As per the review comment from Jens Axboe, I am re-sending this patch
> against "for-6.2/block".
>
>
> Use ktime to change the granularity of IO accounting in block layer from
> milli-seconds to nano-seconds to get the proper
On Wed, Dec 07, 2022 at 11:17:12PM +, Chaitanya Kulkarni wrote:
> On 12/7/22 15:08, Jens Axboe wrote:
> >
> > My default peak testing runs at 122M IOPS. That's also the peak IOPS of
> > the devices combined, and with iostats disabled. If I enabled iostats,
> > then the performance drops to
On 12/7/22 15:08, Jens Axboe wrote:
> On 12/7/22 3:32?PM, Gulam Mohamed wrote:
>> As per the review comment from Jens Axboe, I am re-sending this patch
>> against "for-6.2/block".
>>
>>
>> Use ktime to change the granularity of IO accounting in block layer from
>> milli-seconds to nano-seconds to
On 12/7/22 3:32?PM, Gulam Mohamed wrote:
> As per the review comment from Jens Axboe, I am re-sending this patch
> against "for-6.2/block".
>
>
> Use ktime to change the granularity of IO accounting in block layer from
> milli-seconds to nano-seconds to get the proper latency values for the
>
On 12/7/22 14:32, Gulam Mohamed wrote:
> As per the review comment from Jens Axboe, I am re-sending this patch
> against "for-6.2/block".
>
why is this marked as RFC ? are you waiting for something more to get
resolved so this can be merged ?
>
> Use ktime to change the granularity of IO
As per the review comment from Jens Axboe, I am re-sending this patch
against "for-6.2/block".
Use ktime to change the granularity of IO accounting in block layer from
milli-seconds to nano-seconds to get the proper latency values for the
devices whose latency is in micro-seconds. After changing
On 12/7/22 6:09 AM, Yu Kuai wrote:
> Hi,
>
> 在 2022/12/07 11:15, Ming Lei 写道:
>> On Wed, Dec 07, 2022 at 10:19:08AM +0800, Yu Kuai wrote:
>>> Hi,
>>>
>>> 在 2022/12/07 2:15, Gulam Mohamed 写道:
Use ktime to change the granularity of IO accounting in block layer from
milli-seconds to
On 12/6/22 11:15?AM, Gulam Mohamed wrote:
> Use ktime to change the granularity of IO accounting in block layer from
> milli-seconds to nano-seconds to get the proper latency values for the
> devices whose latency is in micro-seconds. After changing the granularity
> to nano-seconds the iostat
On Tue, 06 Dec 2022 15:40:57 +0100, Christoph Hellwig wrote:
> This macro is obsolete, so replace the last few uses with open coded
> bi_opf assignments.
>
>
Applied, thanks!
[1/1] block: remove bio_set_op_attrs
commit: c34b7ac65087554627f4840f4ecd6f2107a68fd1
Best regards,
--
Jens
On Wed, Dec 07, 2022 at 05:21:48AM -0500, Michael S. Tsirkin wrote:
> Christoph you acked the spec patch adding this to virtio blk:
>
> Still not a fan of the encoding, but at least it is properly documented
> now:
>
> Acked-by: Christoph Hellwig
>
> Did you change your mind
Implement the VIRTIO_BLK_F_LIFETIME feature for VirtIO block devices.
This commit introduces a new ioctl command, VBLK_LIFETIME.
VBLK_LIFETIME ioctl asks for the block device to provide lifetime
information by sending a VIRTIO_BLK_T_GET_LIFETIME command to the device.
lifetime information
Thanks,
I will fix it in the next version.
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, Dec 06, 2022 at 11:31:44AM -0500, Stefan Hajnoczi wrote:
> On Mon, Dec 05, 2022 at 06:20:34PM +0200, Alvaro Karsz wrote:
>
> I don't like that the ioctl lifetime struct is passed through
> little-endian from the device to userspace. The point of this new ioctl
> is not to be a passthrough
Hi,
> Is this based on some spec? Because it looks 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.
Yes, this is based on the virtio spec
On Mon, Dec 05, 2022 at 06:20:34PM +0200, Alvaro Karsz wrote:
I don't like that the ioctl lifetime struct is passed through
little-endian from the device to userspace. The point of this new ioctl
is not to be a passthrough interface. The kernel should define a proper
UABI struct for the ioctl and
On 12/3/22 9:10 AM, Xose Vazquez Perez wrote:
> On 11/30/22 05:56, bmarzins at redhat.com (Benjamin Marzinski) wrote:
>
>> The multpath-tools do not support the io-affinity path selector. We
>> always add a repeat count as the path argument. The io-affinity selector
>> doesn't take one. Instead
Hi Bart,
> Why does the above data structure only refer to SLC and MLC but not to
> TLC or QLC?
This has been discussed before.
The data structure follows the virtio spec
(https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html)
> How will this data structure be extended
On Tue, Nov 29, 2022 at 05:14:28PM +0530, Nitesh Shetty wrote:
> On Thu, Nov 24, 2022 at 08:03:56AM +0800, Ming Lei wrote:
> > On Wed, Nov 23, 2022 at 03:37:12PM +0530, Nitesh Shetty wrote:
> > > On Wed, Nov 23, 2022 at 04:04:18PM +0800, Ming Lei wrote:
> > > > On Wed, Nov 23, 2022 at 11:28:19AM
The original definitions for these fields come from JESD84-B50, which
is what eMMC storage uses. It has been a while, but I recall UFS doing
something pretty similar.
Systems that don't have a well defined notion of durability would just
not expose the flag (e.g. a spinning disk), and going for
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 be a pretty wide range of two/three/etc level cells with wildly
> >> different ranges of
On Tue, Dec 06, 2022 at 11:35:31PM -0800, Christoph Hellwig wrote:
> This just seems like a horrible interface. And virtio-blk should be
> a simple passthrough and not grow tons of side-band crap like this.
>
> If you want to pass through random misc information use virtio-scsi
> or nvme with
Hi,
在 2022/12/07 11:15, Ming Lei 写道:
On Wed, Dec 07, 2022 at 10:19:08AM +0800, Yu Kuai wrote:
Hi,
在 2022/12/07 2:15, Gulam Mohamed 写道:
Use ktime to change the granularity of IO accounting in block layer from
milli-seconds to nano-seconds to get the proper latency values for the
devices whose
On Wed, Dec 07, 2022 at 11:24:00AM +0530, Nitesh Shetty wrote:
> On Tue, Nov 29, 2022 at 05:14:28PM +0530, Nitesh Shetty wrote:
> > On Thu, Nov 24, 2022 at 08:03:56AM +0800, Ming Lei wrote:
> > > On Wed, Nov 23, 2022 at 03:37:12PM +0530, Nitesh Shetty wrote:
> > > > On Wed, Nov 23, 2022 at
Looks good,
Reviewed-by: Johannes Thumshirn
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
This just seems like a horrible interface. And virtio-blk should be
a simple passthrough and not grow tons of side-band crap like this.
If you want to pass through random misc information use virtio-scsi
or nvme with shadow doorbell buffers.
--
dm-devel mailing list
dm-devel@redhat.com
26 matches
Mail list logo
