Hi Nils, Nils Goroll wrote: > Dai, > >> I think we can achieve the same result with a simpler change >> by removing and re-inserting the entry to the head of the list >> once it was selected. The webrev for that change is here: >> >> http://cr.opensolaris.org/~dain/6817942/ >> <http://cr.opensolaris.org/%7Edain/6817942/> > > First of all, sorry for the delay which was on my side this time. > > Regarding your suggested change: > > * Besides clnt_max_conns, there are other static declarations, which > need to be removed. Your proposed changed does not fix these. Yes, this webrev was intended to show the proposed change for the load balancing issue. I removed only the static declaration for clnt_max_conns for testing purpose. > > * The change you propose changes the way the last used cm_xprt entry > is saved - but this does not have anything to do with the root cause > of the issue, which is that using timestamps is inappropriate. I do > not like the fact that your change exploits an unintentional side > effect of the original solution (the fact that the last of the entries > with equivalent x_time is selected) to implement round robin behavior > without doing away the the flawed implementation in the first place. You can look at this as an exploitation, or compensation for a defect, or fixing a flaw, etc. To me it's the end effect with minimal risk. > > On a meta-layer, I think we can come up with hundreds of alternative > solutions to this issue. I have asked for reviews of my proposed > solution and I have not received any. What was your motivation to > propose a completely different approach? My main concern is the stability and performance of the system when changes are made to a sensitive area such as rpcmod. Simpler change is easier to understand and verify, less chance of introducing new bug, less impact to performance of the code. > > I would also like to point our that I have reduced the complexity for > dooming entries (will be done in one go trough the list rather than > starting all over when an entry is doomed), that I hope to have made > the function more concise and that I hope to improve on maintenance by > adding comments. I'm not sure if we need to address this since clnt_max_conns is not expected to change frequently.
Thanks, -Dai