svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[Adrian Chadd]

On 21 January 2015 at 10:15, Gleb Smirnoff <glebius at freebsd.org> wrote:
>   Sean,
>
> On Tue, Jan 20, 2015 at 04:22:44PM -0800, Sean Bruno wrote:
> S> In our universe, this commit (right or wrong) resolved our panics.  I
> S> think that there is some room for improvement based on the commentary
> S> in this thread, but some people do indeed prefer stability over
> S> performance.  I hope we can come to a middle ground somewhere here.
>
> Sorry, but this sounds very much like alchemy. We poured this stuff
> into that stuff and yield in gold precipitate. We don't understand
> what's going on, but let's record the recipe into our tome of aclhemy
> wisdom.
>
> So alchemy never came to a scientific level, and chemistry evolved
> as science only when researchers started to measure, explain and
> understand.
>
> If we treat our precious kernel in alchemy way, we will follow
> the path of alchemy, except that it took centuries for alchemy to
> die, and for a software product it would take a few years.
>
> So, for me Kip ideas sound very sensible. There could be a race
> somewhere else. You tweak callout subsystem in any direction,
> timings of events in kernel shift, your race is hidden.
>
> If we fix problems w/o understanding them, we are going alchemy way.

Hi,

I don't think it's quite this bad.

They originally found that things were spinning for way too long.

Hans found something similar and determined/concluded that the
migration code in callouts was racy-by-design and dramatically
simplified it and also put very hard constraints on what is a valid
situation to support migrating from one callwheel to another. Now we
have fallout which we can either address or back out until the callout
stuff is again reviewed/fixed.

I don't think it's as alchemic as is being promoted.



-a