Eric van Gyzen
2013-Mar-24 03:11 UTC
[patch] IPMI KCS can drop the lock while servicing a request
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. Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: ipmi_kcs.c.patch Type: text/x-patch Size: 429 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130323/35d3ca08/attachment.bin>
Alexander V. Chernikov
2013-Mar-24 22:38 UTC
[patch] IPMI KCS can drop the lock while servicing a request
On 24.03.2013 07:11, 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 suffer from the same problem, too.> > 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 aWell, this seems to be true. I'll try to commit something like this patch in several days.> few months, with no ill effects. > > Eric > > > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
John Baldwin
2013-Apr-02 21:04 UTC
[patch] IPMI KCS can drop the lock while servicing a request
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
Adrian Chadd
2013-Apr-02 22:43 UTC
[patch] IPMI KCS can drop the lock while servicing a request
On 23 March 2013 20:11, Eric van Gyzen <eric at vangyzen.net> 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.Typically holding a lock is to serialise both program state and hardware state. The whole "unlock; do blocking work or sleep; lock" thing needs to be very carefully thought out. Adrian