Hi Alasdair,
On 05/18/2009 08:46 PM +0900, Alasdair G Kergon wrote:
> On Fri, May 15, 2009 at 12:09:21PM +0900, Kiyoshi Ueda wrote:
>> However, if I limit the 'perf' value in smaller range (e.g. 0 to 100),
>> such overflow shouldn't happen. So I should be able to use
>> multiplication. Also, I don't need to use size_t for 'perf',
>> because 'unsinged' should be enough for such small values.
>
> I think a small range would be adequate - look at the number sizes and
> go 0-100 or 0-1000 as appropriate.
>
> Thinking of naming, is it 'relative_throughput' ?
Yes, 'relative_throughput' may be better naming. I'll take it.
> However, is it also going to be possible to extend this target to measure the
> the actual throughput? If we did that, would we use a special value to
> indicate it or add a new table parameter and keep the 'perf' ones as a
> manual adjustment factor applied on top of the calculated one?
The older version of dm-service-time calculated the actual throughput
dynamically using part_stat:
http://marc.info/?l=dm-devel&m=123321314426149&w=2
But the calculated values often had some noises and it didn't work well.
(e.g. Once the throughput value of a path was calculated so small,
the path was never used, and the small throughput value was never
updated, and the path was never used, and ...)
So I think doing such calculations in user-space and simplifying
the kernel-code are better.
For dynamically changing path's bandwidth, user-space daemon can
measure the throughput periodically and notify the dm device.
I've been thinking of adding a new dm message handler to update
'relative_thoughput' in future.
What do you think?
Thanks,
Kiyoshi Ueda
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
