[Gluster-devel] Throttling xlator on the bricks

[Ravishankar N]

On 01/26/2016 01:22 AM, Shreyas Siravara wrote:
> Just out of curiosity, what benefits do we think this throttling xlator would provide over the "enable-least-priority" option (where we put all the fops from SHD, etc into a least pri queue)?
>
>   

For one, it could provide more granularity on the amount of throttling 
you want to do, for specific fops, from specific clients. If the only 
I/O going through the bricks was from the SHD, they would all be 
least-priority but yet consume an unfair % of the CPU. We could tweak 
`performance.least-rate-limit` to throttle but it would be a global option.


>> On Jan 25, 2016, at 12:29 AM, Venky Shankar <vshankar at redhat.com> wrote:
>>
>> On Mon, Jan 25, 2016 at 01:08:38PM +0530, Ravishankar N wrote:
>>> On 01/25/2016 12:56 PM, Venky Shankar wrote:
>>>> Also, it would be beneficial to have the core TBF implementation as part of
>>>> libglusterfs so as to be consumable by the server side xlator component to
>>>> throttle dispatched FOPs and for daemons to throttle anything that's outside
>>>> "brick" boundary (such as cpu, etc..).
>>> That makes sense. We were initially thinking to overload posix_rchecksum()
>>> to do the SHA256 sums for the signer.
>> That does have advantages by avoiding network rountrips by computing SHA* locally.
>> TBF could still implement ->rchecksum and throttle that (on behalf of clients,
>> residing on the server - internal daemons). Placing the core implementation as
>> part of libglusterfs would still provide the flexibility.
>>
>>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gluster.org_mailman_listinfo_gluster-2Ddevel&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=N7LE2BKIHDDBvkYkakYthA&m=9W9xtRg0TIEUvFL-8HpUCux8psoWKkUbEFiwqykRwH4&s=OVF0dZRXt8GFcIxsHlkbNjH-bjD9097q5hjVVHgOFkQ&e=