----- Original Message ----- > From: "Emmanuel Dreyfus" <m...@netbsd.org> > To: "Raghavendra Gowdappa" <rgowd...@redhat.com>, "Pranith Kumar Karampuri" > <pkara...@redhat.com> > Cc: gluster-devel@gluster.org > Sent: Wednesday, September 2, 2015 8:12:37 PM > Subject: Re: [Gluster-devel] FOP ratelimit? > > Raghavendra Gowdappa <rgowd...@redhat.com> wrote: > > > Its helpful if you can give some pointers on what parameters (like > > latency, throughput etc) you want us to consider for QoS. > > Full blown QoS would be nice, but a first line of defense against > resource hogs seems just badly required. > > A bare minimum could be to process client's FOP in a round robin > fashion. That way even if one client sends a lot of FOPs, there is > always some window for others to slip in. > > Any opinion?
As of now we depend on epoll/poll events informing servers about incoming messages. All sockets are put in the same event-pool represented by a single poll-control fd. So, the order of our processing of msgs from various clients really depends on how epoll/poll picks events across multiple sockets. Do poll/epoll have any sort of scheduling? or is it random? Any pointers on this are appreciated. > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > m...@netbsd.org > _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel