From owner-freebsd-stable@FreeBSD.ORG Tue Apr 2 21:08:08 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AB10BE82 for ; Tue, 2 Apr 2013 21:08:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8AD60ABC for ; Tue, 2 Apr 2013 21:08:08 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E1388B964; Tue, 2 Apr 2013 17:08:07 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: [patch] IPMI KCS can drop the lock while servicing a request Date: Tue, 2 Apr 2013 17:04:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <514E6ED8.9040305@vangyzen.net> In-Reply-To: <514E6ED8.9040305@vangyzen.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201304021704.07197.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 02 Apr 2013 17:08:08 -0400 (EDT) Cc: Eric van Gyzen X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 21:08:08 -0000 On Saturday, March 23, 2013 11:11:20 pm Eric van Gyzen wrote: > At work, we discovered that our application's IPMI thread would often > use a lot of CPU time. The KCS thread uses DELAY to wait for the BMC, > so it can run without sleeping for a "long" time with a slow BMC. It > also holds the ipmi_softc.ipmi_lock during this time. When using > adaptive mutexes, an application thread that wants to operate on the > ipmi_pending_requests list will also spin during this same time. > > We see no reason that the KCS thread needs to hold the lock while > servicing a request. We've been running with the attached patch for a > few months, with no ill effects. The lock protects against concurrent access to the registers themselves (though the thread sort of does this already). However, even with a slow BMC it shouldn't be waiting but so long. I had some other comments about this patch in my reply to when it was committed. -- John Baldwin