From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH v2] drm: do not sleep on vblank while holding a mutex Date: Sat, 29 Oct 2011 16:11:45 +0200 Message-ID: <20111029141145.GE2932@phenom.ffwll.local> References: <1319838143-2318-1-git-send-email-ihadzic@research.bell-labs.com> <20111029005819.GF2919@phenom.ffwll.local> <20111029100020.GC2932@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wy0-f177.google.com (mail-wy0-f177.google.com [74.125.82.177]) by gabe.freedesktop.org (Postfix) with ESMTP id AC7A09E85A for ; Sat, 29 Oct 2011 07:10:51 -0700 (PDT) Received: by wyg8 with SMTP id 8so5891807wyg.36 for ; Sat, 29 Oct 2011 07:10:50 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Ilija Hadzic Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Sat, Oct 29, 2011 at 06:59:42AM -0500, Ilija Hadzic wrote: > On Sat, 29 Oct 2011, Daniel Vetter wrote: > >Ok, and here's why your locking (or any locking that drops the lock before > >calling schedule) won't work: [SNIP] > > You just came full circle. Recall that in my v1 patch I went all the > way to enqueuing the process in the wait queue before dropping the > lock. That would have guaranteed that if there is a hangup, what > last_vblank_wait says is the last is really the last. If there is no > hang, then it doesn't matter because last_vlank_wait is constantly > overwritten (and is indeed stale for N-1 processes). However, that > was disliked in the review and I didn't want to argue. Not quite full circle. Holding the lock until you're on the waitqueue doesn't really change anything - we wake up everybody on every vblank anyway. The thing I was nitpicking over was that vblank_last_wait isn't really protected on the read side, but as you've pointed out, that's not a big problem. Essentially the only thing about vblank_last_wait that we can guarantee is that somewhen somebody tried to wait on this vblank. Nothing else is possible (and the reason why I think we should ditch this all and replace it we some decent tracing - material for a differen patch though). > So in the interest of making progress, it looks that you would be > happy if this patch just dropped DRM_UNLOCKED and declared that we > don't care about (potentially theoretical) critical section related > to last_vblank_wait. > > If that's the case, I'll cut a relatvely trivial patch that drops > DRM_UNLOCKED from this system call to solve the problem that I > pointed earlier in this thread and leave all the rest of the locking > discussion for other patches. > > Would that be fine by you ? Yeah. Cheers, Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48