Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190419120207.GO4038@hirez.programming.kicks-ass.net>
 <20190419130304.GV14281@hirez.programming.kicks-ass.net> <20190419131522.GW14281@hirez.programming.kicks-ass.net>
 <57620139-92a3-4a21-56bd-5d6fff23214f@redhat.com> <7b1bfc26-6e90-bd65-ab46-08413acd80e9@redhat.com>
 <20190423141714.GO11158@hirez.programming.kicks-ass.net> <CAHk-=whnQJ9YDrkcKteNSACMJxzw1bL0RPfGQsey_9Nm7b8mnw@mail.gmail.com>
 <4f62d7f2-e5f6-500e-3e70-b1d1978f7140@redhat.com> <20190424070959.GE4038@hirez.programming.kicks-ass.net>
 <51589ac0-3e1f-040e-02bf-b6de77cbda1d@redhat.com> <20190424170148.GR12232@hirez.programming.kicks-ass.net>
In-Reply-To: <20190424170148.GR12232@hirez.programming.kicks-ass.net>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed, 24 Apr 2019 10:56:04 -0700
Message-ID: <CAHk-=whA4dDdp+KT_ZWnKr5ERqhUtsf3wRTh7HL1Dcg0vGYV_g@mail.gmail.com>
Subject: Re: [PATCH v4 14/16] locking/rwsem: Guard against making count negative
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Waiman Long <longman@redhat.com>, Ingo Molnar <mingo@redhat.com>,
        Will Deacon <will.deacon@arm.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
        "the arch/x86 maintainers" <x86@kernel.org>,
        Davidlohr Bueso <dave@stgolabs.net>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        huang ying <huang.ying.caritas@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Apr 24, 2019 at 10:02 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> > For an uncontended rwsem, this offers no real benefit. Adding
> > preempt_disable() is more complicated than I originally thought.
>
> I'm not sure I get your objection?

I'm not sure it's an objection, but I do think that it's sad if we
have to do the preempt_enable/disable around the fastpath.

Is the *only* reason for the preempt-disable to avoid the (very
unlikely) case of unbounded preemption in between the "increment
reader counts" and "decrement it again because we noticed it turned
negative"?

If that's the only reason, then I think we should just accept the
race. You still have a "slop" of 15 bits (so 16k processes) hitting
the same mutex, and they'd all have to be preempted in that same
"small handful instructions" window.

Even if the likelihood of *one* process hitting that race is 90% (and
no, it really isn't), then the likelihood of having 16k processes
hitting that race is 0.9**16384.

We call numbers like that "we'll hit it some time long after the heat
death of the universe" numbers.

     Linus