Re: [Nfs-ganesha-devel] Ganesha 2.6.3 Segfault
There was a timing problem with my 2.6 code, that I'd fixed last April and flagged to be backported. This might be another manifestation. I'd debugged it during transport shutdown. From the #132 commit notes: The thread scheduler doesn't necessarily do work in the order submitted. In this case, the scheduler can/will run the per transport cleanup task before other ready worker tasks, causing timing conflicts with the service request channel task. Use the channel task to free transports. Client call timeout is most likely increasing relative to other calls for the same connection, worst case for rbtree insertion. Profiling showed that rbtree was not a good choice, and TAILQ improved by 200%. Moreover, maintaining the potentially large list of timeouts in the service request was slowing event response. Instead, keep only one entry per transport, with callback timeouts maintained by transport.
On Mon, Oct 1, 2018 at 10:38 AM, William Allen Simpson <william.allen.simpson@gmail.com> wrote:
Client call timeout is most likely increasing relative to other calls for the same connection, worst case for rbtree insertion. Profiling showed that rbtree was not a good choice, and TAILQ improved by 200%.
I do not believe this to be significant to the discussion (nor to be a valid analysis, but I've written that elsewhere).
Moreover, maintaining the potentially large list of timeouts in the service request was slowing event response. Instead, keep only one entry per transport, with callback timeouts maintained by transport. _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
-- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309
participants (2)
-
Matt Benjamin -
William Allen Simpson