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@xxxxxxxxxx> 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@xxxxxxxxxxx
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=
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
