On Mon, Oct 03, 2016 at 03:20:57PM -0400, bdegraaf at codeaurora.org wrote:

On 2016-10-01 14:11, Mark Rutland wrote:

quoted

Hi Brent,

Evidently my questions weren't sufficiently clear; even with your
answers it's not clear to me what precise issue you're attempting to
solve.  I've tried to be more specific this time.

At a high-level, can you clarify whether you're attempting to solve is:

(a) a functional correctness issue (e.g. data corruption)
(b) a performance issue

And whether this was seen in practice, or found through code
inspection?

Thinking about this, as the reader/writer code has no known "abuse"
case, I'll remove it from the patchset, then provide a v2 patchset
with a detailed explanation for the lockref problem using the commits
you provided as an example, as well as performance consideration.

If there's a functional problem, let's consider that in isolation first.
Once we understand that, then we can consider doing what is optimal.

As should be obvious from the above, I'm confused because this patch
conflates functional details with performance optimisations which (to
me) sound architecturally dubious.

I completely agree with Peter that if the problem lies with lockref, it
should be solved in the lockref code.

Thanks,
Mark.