> On Dec 30, 2015, at 2:31 AM, Niels de Vos <ndevos@xxxxxxxxxx> wrote: > >> I'm guessing that Linux uses the event-epoll stuff instead of event-poll, >> so it wouldn't exhibit this. Is that correct? > > Well, both. most (if not all) Linux builds will use event-poll. But, > that calls epoll_wait() with a timeout of 1 millisecond as well. > >> Thanks for any information on this, rick >> ps: I am tempted to just crank the timeout of 1msec up to 10 or 20msec. > > Yes, that is probably what I would do too. And have both poll functions > use the same timeout, have it defined in libglusterfs/src/event.h. We > could make it a configurable option too, but I do not think it is very > useful to have. I guess this begs the question - what’s the actual purpose of polling for an event with a 1 millisecond timeout? If it was some sort of heartbeat check, one might imagine that would be better served by a timer with nothing close to 1 millisecond as an interval (that would be one seriously aggressive heartbeat) and if filesystem events are incoming that glusterfs needs to respond to, why timeout at all? I also have a broader question to go with the specific one: We (at iXsystems) were attempting to engage with some of the Red Hat folks back when the FreeBSD port was first done, in the hope of getting it more “officially supported” for FreeBSD and perhaps even donating some more serious stress-testing and integration work for it, but when those Red Hat folks moved on we lost continuity and the effort stalled. Who at Red Hat would / could we work with in getting this back on track? We’d like to integrate glusterfs with FreeNAS 10, and in fact have already done so but it’s still early days and we’re not even really sure what we have yet. Thanks, - Jordan _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel