I would appreciate if whoever understands RX (rx.c) could comment on this:
With rx_EnableHotThread() set in the (pthread_) fileserver, under certain
circumstances the current thread's ID (the thing set by
pthread_setspecific(rx_thread_id_key,...) ) is changed:
if (rx_enable_hot_thread && newcallp && sq->socketp) {
...
*tnop = sq->tno;
...
Curiously, this is a one-way change, not a swap, with two threads ending up
with the same thread-id afterwards. I fail to see a replenishing mechanism
which would prevent the system from evolving to a single-thread-id
constellation over time.
Going through a number of 'mature' fileserver dumps, indeed they show a
drastically reduced diversity of the values of 'threadID' in the various
rxi_ServerProc stack frames - usually 0, 1 or 2.
A quick test shows that after disabling rx_enable_hot_thread in the fileserver
this does NOT happen, after 10 hours of reasonable traffic all thread ids are
still represented, no duplicates.
Of course the next step is to change rx.c and SWAP the tno's - but I'm afraid
that this code is actually executed pretty rarely and a swap might just create
a problem that passes unnoticed for a long time.
[the per thread rx_thread_id_key (alias threadID, alias tno, alias
h_lwpIndex()) is vital for the h_Hold() mechanism, and failed for us even with
the recently posted patches for the housekeeping threads applied].
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke http://cern.ch/~rtb [EMAIL PROTECTED] O__
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland > |
Phone: +41 22 767 8985 Fax: +41 22 767 7155 ( )\( )
_______________________________________________
OpenAFS-devel mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-devel
