Date: Thu, 7 Jan 2016 19:10:21 +0100 From: Niels de Vos <ndevos@redhat.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: gluster-devel@gluster.org, freebsd-fs <freebsd-fs@freebsd.org>, Shyam Ranganathan <srangana@redhat.com> Subject: Re: [Gluster-devel] FreeBSD port of GlusterFS racks up a lot of CPU usage Message-ID: <20160107181021.GK27495@ndevos-x240.usersys.redhat.com> In-Reply-To: <923007690.145828058.1451484032304.JavaMail.zimbra@uoguelph.ca> References: <571237035.145690509.1451437960464.JavaMail.zimbra@uoguelph.ca> <20151230103152.GS13942@ndevos-x240.usersys.redhat.com> <923007690.145828058.1451484032304.JavaMail.zimbra@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
--9q+4pEgVd7t11q9L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 30, 2015 at 09:00:32AM -0500, Rick Macklem wrote: > Niels de Vos wrote: > > On Tue, Dec 29, 2015 at 08:12:40PM -0500, Rick Macklem wrote: > > > Hi, > > >=20 > > > I'm been playing with the FreeBSD port of GlusterFS and it seems > > > to be working ok. I do notice that the daemons use a lot of CPU, > > > even when there is nothing to do (no volumes started, etc). > > > When I ktrace the daemon, I see a small number of nanosleep() and > > > select() syscalls and lots of poll() syscalls (close to 1000/sec). > > >=20 > > > Looking at libglusterfs/src/event-poll.c, I find: > > > ret =3D poll(ufds, size, 1); > > > in a loop. The only thing the code seems to do when poll() times > > > out is a call to event_dispatch_poll_resize(). > > >=20 > > > So, is it necessary to call event_dispatch_poll_resize() 1000 times > > > per second? > > > Or is there a way to make event_dispatch_poll_resize() return quickly > > > when there is nothing to do? > >=20 > > I do not think this is critical. A longer timeout should be well > > acceptable. > >=20 > > > I'm guessing that Linux uses the event-epoll stuff instead of event-p= oll, > > > so it wouldn't exhibit this. Is that correct? > >=20 > > 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. > >=20 > Actually, when I look at the 3.7.6 sources in libglusterfs/src/event-epol= l.c > I only find one epoll_wait() at line#668: > ret =3D epoll_wait (event_pool->fd, &event, 1, -1); > so the timeout never happens in this code. > (It does have code after the call to handle the timeout case.) > All it seems to do (if it were to timeout) is adjust the # of threads in = the > event-epoll case, so my hunch is that a timeout isn't needed? Oh, yes, indeed, my mistake. > For the event-poll.c case, it calls event_dispatch_poll_size() which look= s like > it might add new file descriptors, so someone more familiar with this cod= e would > need to decide if the timeout can be disabled (my hunch is no, but I'm no= t familiar > with the code). Maybe Shyam (on CC) knows more how event-poll works. He is definitely one of the developers that could explain epoll, and I guess he looked into poll too. Niels > > > Thanks for any information on this, rick > > > ps: I am tempted to just crank the timeout of 1msec up to 10 or 20mse= c. > >=20 > > 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. > >=20 > > Could you file a bug and/or send a patch for this? > >=20 > I will try bumping the timeout up in event-poll.c and if it seems to redu= ce > CPU usage and not cause any obvious grief, I will file a bug report. >=20 > Thanks for your help with this, rick >=20 > > Thanks, > > Niels > >=20 --9q+4pEgVd7t11q9L Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWjqoNAAoJECXo5AApwsWzRlsP/iWp6VZReXrr/rix+kasiF1g YnMjvA4zS6AFSklXvcOifkvmpjr8VjHAqsoxWHOinZDLikk7m3Cbu5z+2wSLzUHh fQkY0n/s9fl6Ji4orX11CesetZAfMsNUZgn9qMqxu2zJf2zte1m5FbyvLNHfBdoe PdlAYJQGYEP6uD2hr8tNx6s37w5ypAwNRDuVK6nH0sZwYiQiY2uIxODaz0rf5zci gOKwvy2RDgKvUvDW5Jfq+sCCsm/KENkthENfQf8IWglNJhNwjPK5i/1CHPLKZk5e bvD9THZSsPoj5joCUuh1OfVsTj7AZMyasL3C5mL/NfWtOYBfIk0qFwzrvf9LZoWC d3P540PT0a2SogvrBa+NSsZeXCz1xT6A8M/wukCoX8t0WJ7gAvJukG6djbhQ75ZB xFUfACApwby5Z/JP1LYKJ5Npvd21Dse5HVxdyy0+mME89KJOjBGrbl7gry1Pks4R w4OgUuTqRPVN8XfMzXtPRZEXzLTNr33B3dSKFIoChPY60Tl6w2NgXHtFL/lbYNqb FxivkegF7Sq+fTb8hmmITCAVWYtyrm0So0LdFQCzBDgBQix5D5q/+ioj9Ralhk4d SbcLs5euksBzGeUfSgOf7MGAmXlkBRimn4j5HeE8TZ5zK90tVuP+Ohm5irAQnBvs g4YPOuWMzMqBXjlZ+EkT =3307 -----END PGP SIGNATURE----- --9q+4pEgVd7t11q9L--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160107181021.GK27495>