| Message ID | 1379067909-22984-6-git-send-email-pl@kamp.de |
|---|---|
| State | New |
| Headers | show |
Il 13/09/2013 12:25, Peter Lieven ha scritto: > + /* maximum number of sectors that can be discarded at once */ > + int max_discard; > + /* maximum number of sectors that can zeroized at once */ > + int max_write_zeroes; These should not be needed outside the driver. If you want to make them private between block.c and block/iscsi.c, you can add them to BlockDriverState. Paolo
On 13.09.2013 12:34, Paolo Bonzini wrote: > Il 13/09/2013 12:25, Peter Lieven ha scritto: >> + /* maximum number of sectors that can be discarded at once */ >> + int max_discard; >> + /* maximum number of sectors that can zeroized at once */ >> + int max_write_zeroes; > These should not be needed outside the driver. > > If you want to make them private between block.c and block/iscsi.c, you > can add them to BlockDriverState. The question is, if the discard_zeroes or discard_write_zeroes is needed outside the driver as well? I can put the max_* information in the block driver state. I also thought to add alignment and granularity information even if they are currently not yet used. Peter
Il 13/09/2013 12:44, Peter Lieven ha scritto: > On 13.09.2013 12:34, Paolo Bonzini wrote: >> Il 13/09/2013 12:25, Peter Lieven ha scritto: >>> + /* maximum number of sectors that can be discarded at once */ >>> + int max_discard; >>> + /* maximum number of sectors that can zeroized at once */ >>> + int max_write_zeroes; >> These should not be needed outside the driver. >> >> If you want to make them private between block.c and block/iscsi.c, you >> can add them to BlockDriverState. > The question is, if the discard_zeroes or discard_write_zeroes is needed > outside the driver as well? > > I can put the max_* information in the block driver state. I also thought > to add alignment and granularity information even if they are currently > not yet used. Yeah, in fact bdrv_write_zeroes and bdrv_discard can be taught to split requests according to these parameters instead of introducing a new function bdrv_zeroize. You don't need bdrv_zeroize I think; you can simply use bdrv_write_zeroes. This is why I don't like this information in BlockDriverInfo. On the contrary, discard_write_zeroes is useful to "generic" clients, and your qemu-img patch shows why. Discard_zeroes is somewhere in the middle. You only use it in bdrv_get_block_status, but it is not something that should be hidden to users of the high-level block.c API. So it is fine to leave it in BlockDriverInfo. Paolo
Am 13.09.2013 13:45, schrieb Paolo Bonzini: > Il 13/09/2013 12:44, Peter Lieven ha scritto: >> On 13.09.2013 12:34, Paolo Bonzini wrote: >>> Il 13/09/2013 12:25, Peter Lieven ha scritto: >>>> + /* maximum number of sectors that can be discarded at once */ >>>> + int max_discard; >>>> + /* maximum number of sectors that can zeroized at once */ >>>> + int max_write_zeroes; >>> These should not be needed outside the driver. >>> >>> If you want to make them private between block.c and block/iscsi.c, you >>> can add them to BlockDriverState. >> The question is, if the discard_zeroes or discard_write_zeroes is needed >> outside the driver as well? >> >> I can put the max_* information in the block driver state. I also thought >> to add alignment and granularity information even if they are currently >> not yet used. > Yeah, in fact bdrv_write_zeroes and bdrv_discard can be taught to split > requests according to these parameters instead of introducing a new > function bdrv_zeroize. You don't need bdrv_zeroize I think; you can > simply use bdrv_write_zeroes. This is why I don't like this information > in BlockDriverInfo. bdrv_zeroize has one big advantage over a bdrv_write_zeroes over the whole device: it checks the block status before it sends requests. this can be a great performance benefit if a lot of blocks are already unmapped. so i would like to keep it in, but simplifiy it (see below). > > On the contrary, discard_write_zeroes is useful to "generic" clients, > and your qemu-img patch shows why. > > Discard_zeroes is somewhere in the middle. You only use it in > bdrv_get_block_status, but it is not something that should be hidden to > users of the high-level block.c API. So it is fine to leave it in > BlockDriverInfo. okay, i will leave them in and put max_discard discard_alignment max_write_zeroes write_zeroes_alignment into the BlockDriverState. I would then like to call out to all driver developers to set these values for their drivers to good values. For now I can factor out the request split logic out of iscsi_co_discard, iscsi_co_write_zeroes and bdrv_sanitize and put them in bdrv_co_discard and bdrv_co_write_zeroes. I would like to leave the misalignment logic to a later patch. What would you think are reasonable default values for max_discard and max_write_zeroes? Peter
Il 13/09/2013 14:22, Peter Lieven ha scritto: > Am 13.09.2013 13:45, schrieb Paolo Bonzini: >> Il 13/09/2013 12:44, Peter Lieven ha scritto: >>> On 13.09.2013 12:34, Paolo Bonzini wrote: >>>> Il 13/09/2013 12:25, Peter Lieven ha scritto: >>>>> + /* maximum number of sectors that can be discarded at once */ >>>>> + int max_discard; >>>>> + /* maximum number of sectors that can zeroized at once */ >>>>> + int max_write_zeroes; >>>> These should not be needed outside the driver. >>>> >>>> If you want to make them private between block.c and block/iscsi.c, you >>>> can add them to BlockDriverState. >>> The question is, if the discard_zeroes or discard_write_zeroes is needed >>> outside the driver as well? >>> >>> I can put the max_* information in the block driver state. I also thought >>> to add alignment and granularity information even if they are currently >>> not yet used. >> Yeah, in fact bdrv_write_zeroes and bdrv_discard can be taught to split >> requests according to these parameters instead of introducing a new >> function bdrv_zeroize. You don't need bdrv_zeroize I think; you can >> simply use bdrv_write_zeroes. This is why I don't like this information >> in BlockDriverInfo. > > bdrv_zeroize has one big advantage over a bdrv_write_zeroes over > the whole device: it checks the block status before it sends requests. > this can be a great performance benefit if a lot of blocks are already > unmapped. so i would like to keep it in, but simplifiy it (see below). Good idea. > For now I can factor out the request split logic out of > iscsi_co_discard, iscsi_co_write_zeroes and bdrv_sanitize > and put them in bdrv_co_discard and bdrv_co_write_zeroes. > > I would like to leave the misalignment logic to a later patch. Sure. > What would you think are reasonable default values for > max_discard and max_write_zeroes? 32768 (16 MB) is the highest power-of-two amount that fits in 16 bits assuming 512-byte sectors. But you could also take a look at what the Linux kernel does in drivers/scsi/sd.c. Paolo
On 13.09.2013 13:45, Paolo Bonzini wrote: > Il 13/09/2013 12:44, Peter Lieven ha scritto: >> On 13.09.2013 12:34, Paolo Bonzini wrote: >>> Il 13/09/2013 12:25, Peter Lieven ha scritto: >>>> + /* maximum number of sectors that can be discarded at once */ >>>> + int max_discard; >>>> + /* maximum number of sectors that can zeroized at once */ >>>> + int max_write_zeroes; >>> These should not be needed outside the driver. >>> >>> If you want to make them private between block.c and block/iscsi.c, you >>> can add them to BlockDriverState. >> The question is, if the discard_zeroes or discard_write_zeroes is needed >> outside the driver as well? >> >> I can put the max_* information in the block driver state. I also thought >> to add alignment and granularity information even if they are currently >> not yet used. > Yeah, in fact bdrv_write_zeroes and bdrv_discard can be taught to split > requests according to these parameters instead of introducing a new > function bdrv_zeroize. You don't need bdrv_zeroize I think; you can > simply use bdrv_write_zeroes. This is why I don't like this information > in BlockDriverInfo. > > On the contrary, discard_write_zeroes is useful to "generic" clients, > and your qemu-img patch shows why. > > Discard_zeroes is somewhere in the middle. You only use it in > bdrv_get_block_status, but it is not something that should be hidden to > users of the high-level block.c API. So it is fine to leave it in > BlockDriverInfo. Would you also be ok to introduce bdrv_has_discard_zeroes() and bdrv_has_discard_write_zeroes() as Kevin suggested to avoid the need to add the logic to return 0 if there is a bs->backing_hd everywhere. This would also make the use of it easier as it avoids the steps necessary to invoke bdrv_get_info(). Peter
Il 16/09/2013 13:30, Peter Lieven ha scritto: > On 13.09.2013 13:45, Paolo Bonzini wrote: >> Il 13/09/2013 12:44, Peter Lieven ha scritto: >>> On 13.09.2013 12:34, Paolo Bonzini wrote: >>>> Il 13/09/2013 12:25, Peter Lieven ha scritto: >>>>> + /* maximum number of sectors that can be discarded at once */ >>>>> + int max_discard; >>>>> + /* maximum number of sectors that can zeroized at once */ >>>>> + int max_write_zeroes; >>>> These should not be needed outside the driver. >>>> >>>> If you want to make them private between block.c and block/iscsi.c, you >>>> can add them to BlockDriverState. >>> The question is, if the discard_zeroes or discard_write_zeroes is needed >>> outside the driver as well? >>> >>> I can put the max_* information in the block driver state. I also >>> thought >>> to add alignment and granularity information even if they are currently >>> not yet used. >> Yeah, in fact bdrv_write_zeroes and bdrv_discard can be taught to split >> requests according to these parameters instead of introducing a new >> function bdrv_zeroize. You don't need bdrv_zeroize I think; you can >> simply use bdrv_write_zeroes. This is why I don't like this information >> in BlockDriverInfo. >> >> On the contrary, discard_write_zeroes is useful to "generic" clients, >> and your qemu-img patch shows why. >> >> Discard_zeroes is somewhere in the middle. You only use it in >> bdrv_get_block_status, but it is not something that should be hidden to >> users of the high-level block.c API. So it is fine to leave it in >> BlockDriverInfo. > > Would you also be ok to introduce bdrv_has_discard_zeroes() > and bdrv_has_discard_write_zeroes() as Kevin suggested to avoid the need to > add the logic to return 0 if there is a bs->backing_hd everywhere. If Kevin says it, I agree. :) > This would also make the use of it easier as it avoids the steps > necessary to invoke bdrv_get_info(). Another possibility could be to put the "info" in a member of BlockDriverState, since it is static. Then bdrv_get_info() could be simply return &bs->info; which is faster and removes the need for a BlockDriverInfo temporary. Paolo
diff --git a/include/block/block.h b/include/block/block.h index 599de7d..ee17048 100644 --- a/include/block/block.h +++ b/include/block/block.h @@ -18,6 +18,15 @@ typedef struct BlockDriverInfo { /* offset at which the VM state can be saved (0 if not possible) */ int64_t vm_state_offset; bool is_dirty; + /* do discarded blocks read back as zeroes? */ + bool discard_zeroes; + /* is write zeroes optimized by a discard/unmap operation? + * this requires support for the BDRV_REQ_MAY_UNMAP flag. */ + bool discard_write_zeroes; + /* maximum number of sectors that can be discarded at once */ + int max_discard; + /* maximum number of sectors that can zeroized at once */ + int max_write_zeroes; } BlockDriverInfo; typedef struct BlockFragInfo {
Signed-off-by: Peter Lieven <pl@kamp.de> --- include/block/block.h | 9 +++++++++ 1 file changed, 9 insertions(+)