On 01/23/2015 03:12 PM, Emmanuel Dreyfus wrote:
Shyam <srangana@xxxxxxxxxx> wrote:
Patch: http://review.gluster.org/#/c/3842/
Manu,
I was not able to find the NetBSD job mentioned in the last review
comment provided by you, pointers to that would help.
Yes, sorry, both regression tests hang and I had to reboot the machine,
hence you do not have the reports in gerrit:
http://build.gluster.org/job/rackspace-netbsd7-regression-triggered/731
http://build.gluster.org/job/rackspace-netbsd7-regression-triggered/741
Since I got the same horrible result, I did not try retriggering one
more time, feel free to try it if you need to.
What is the support status of epoll on NetBSD? I though NetBSD favored
the kqueue means of event processing over epoll and that epoll was not
supported on NetBSD (or *BSD).
No support for epoll on NetBSD. The alternative would indeed be kqueue,
but not code has been written to support it. glusterfs on NetBSD uses
plain poll code right now.
I ask this, as this patch specifically changes the number of epoll
threads, as a result, it is possibly having a different affect on
NetBSD, which should either be on poll or kqueue (to my understanding).
I have not looked at the reasons right now, but it must be something
outside of epoll code since NetBSD does not use it.
Various tests on Linux constantly exercise the epoll option, and there
are changes in the socket and poll code in this commit as well. I would
assume something here causing a problem, unless others have run this
through a poll mechanism.
Here is what I indent to do,
- Run with epoll disabled (or poll enabled) on my local box, to see if
any surprises crop up
- Try the same on the regression suites on gerrit (after some of the
more recent runs are done)
Manu, request you to go through the non-epoll changes in the submitted
patch to see if something catches your eye?
Shyam
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
