Ted Baker wrote: > On Tue, Jul 14, 2009 at 12:24:26PM -0600, Chris Friesen wrote: > >>> - that A's budget is not diminished. >> If we're running B with A's priority, presumably it will get some amount >> of cpu time above and beyond what it would normally have gotten during a >> particular scheduling interval. Perhaps it would make sense to charge B >> what it would normally have gotten, and charge the excess amount to A? > So, it seems most logical and simplest to leave the charges where > they naturally occur, on B. That is, if you allow priority > inheritance, you allow tasks to sometimes run at higher priority > than they originally were allocated, but not to execute more > than originally budgeted. I had considered this myself, as the simplicity is appealing. In this scenario, we're going to disrupt B's scheduling pattern by forcing it to borrow from its future cpu allocation in order to free up the lock. It will then be forced to block for a while to make up for the over-use of it's cpu budget. I was worried that this "bursty" behaviour could cause problems, but on reflection it seems like if the application is well-behaved to start with, maybe we can assume that lock-hold times will be small enough that this shouldn't cause significant problems. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
