Re: [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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [patch] IPMI KCS can drop the lock while servicing a request
On 23 March 2013 20:11, Eric van Gyzen e...@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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [patch] IPMI KCS can drop the lock while servicing a request
On 25.03.2013 02:38, Alexander V. Chernikov wrote: 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 a Well, this seems to be true. I'll try to commit something like this patch in several days. Done in r248705. few months, with no ill effects. Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- WBR, Alexander ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [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 a Well, 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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[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
diff --git a/sys/dev/ipmi/ipmi_kcs.c b/sys/dev/ipmi/ipmi_kcs.c
index 1ca3298..868570d 100644
--- a/sys/dev/ipmi/ipmi_kcs.c
+++ b/sys/dev/ipmi/ipmi_kcs.c
@@ -456,9 +456,11 @@ kcs_loop(void *arg)
IPMI_LOCK(sc);
while ((req = ipmi_dequeue_request(sc)) != NULL) {
+ IPMI_UNLOCK(sc);
ok = 0;
for (i = 0; i 3 !ok; i++)
ok = kcs_polled_request(sc, req);
+ IPMI_LOCK(sc);
if (ok)
req-ir_error = 0;
else
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
