Re: [PATCH v2] blk-throttle: simplify logic by token bucket algorithm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



How about take the basic token bucket algorithm first, and consider
optimize options later? Such as:
 - limit the idle reserve
 - change the static depth of token bucket
 - calculate the depth of token bucket according to configured bps rate
 - export the depth of token bucket to user space

On Wed, Oct 16, 2013 at 11:53 PM, Tejun Heo <tj@xxxxxxxxxx> wrote:
> Hello,
>
> On Wed, Oct 16, 2013 at 10:14:06AM -0400, Vivek Goyal wrote:
>> - First of all, if you think that a group is entitiled for tokens even
>>   when it is not doing IO, then why are you truncating the tokens after
>>   dispatch of a BIO.
>>
>> - Second in general it does not seem right that a group is entitiled to
>>   tokens even when no IO is happening or group is not backlogged. That
>>   would mean a group will not do IO for 10 hours and then be entitiled
>>   to those tokens suddenly after 10 hours with a huge burst.
>>
>> So I think you also agree that a group should not be entitiled to
>> tokens when group is not backlogged and that's why you seem to be
>> truncating extra tokens after dispatch of a BIO. If that's the case,
>> then even for first BIO, ideally a group should not be given tokens
>> for idle time.
>
> Without going into details, having token reserve is an important part
> of token based implementation.  The large the reserve could be
> debatable but that's what provides "smoothing" of allocation.  e.g. if
> you trim bucket as soon as the queue becomes empty, a queue with
> sequential access pattern can easily get disadvantaged.  Another way
> to look at it is to consider as though the IO has been issued some
> time before than actual and waited for the token - it is the same to
> external observers.
>
> So, while how large the reserve should be is definitely debatable,
> bucket scheduling *needs* idle reserve.
>
> Thanks.
>
> --
> tejun



-- 
best regards
Hong Zhiguo
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux