Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751451Ab3CNHZN (ORCPT ); Thu, 14 Mar 2013 03:25:13 -0400 Received: from mail-ia0-f173.google.com ([209.85.210.173]:51844 "EHLO mail-ia0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751136Ab3CNHZK (ORCPT ); Thu, 14 Mar 2013 03:25:10 -0400 MIME-Version: 1.0 In-Reply-To: <1363223574.25976.135.camel@thor.lan> References: <1361390599-15195-1-git-send-email-peter@hurleysoftware.com> <1363034704-28036-1-git-send-email-peter@hurleysoftware.com> <1363106846.27803.174.camel@thor.lan> <1363223574.25976.135.camel@thor.lan> Date: Thu, 14 Mar 2013 00:25:09 -0700 Message-ID: Subject: Re: [PATCH v5 00/44] ldisc patchset From: Michel Lespinasse To: Peter Hurley Cc: Greg Kroah-Hartman , Jiri Slaby , Sasha Levin , Dave Jones , Sebastian Andrzej Siewior , Shawn Guo , linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1787 Lines: 38 On Wed, Mar 13, 2013 at 6:12 PM, Peter Hurley wrote: > On Wed, 2013-03-13 at 04:36 -0700, Michel Lespinasse wrote: >> Have you considered building your ldlock based on lib/rwsem-spinlock.c >> instead ? i.e. having an internal spinlock to protect the ldisc >> reference count and the reader and writer queues. This would seem much >> simpler get right. The downside would be that a spinlock would be >> taken for a short time whenever an ldisc reference is taken or >> released. I don't expect that the internal spinlock would get >> significant contention ? > > That would have been too easy :) > > TBH, I hadn't considered it until I was most the way through a working > atomic version. I had already split the reader/writer wait lists. And > figured out how to always use the wait bias for every waiting reader and > writer -- rather than the rwsem way of testing for an empty list -- > which made the timeout handling easier. > > At the time, the only thing that I was still struggling with was > recursion, and the spinlock flavor wasn't going to fix that. So I just > kept with the atomic flavor. Its not too late to run away from it and preserve your sanity (as well as that of the next person working on the tty layer :) I think I know that rwsem code pretty well by now and I still get surprised here and there, as in our other discussion... Seriously, things will be easier if you can use an internal spinlock. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/