[Skiboot] [PATCH] Rate limit OPAL_MSG_OCC to only one outstanding message to host
Stewart Smith
stewart at linux.vnet.ibm.com
Mon Sep 28 13:45:44 AEST 2015
Patrick Williams <patrick at stwcx.xyz> writes:
> On Fri, Sep 25, 2015 at 04:40:00PM +1000, Stewart Smith wrote:
>> Patrick Williams <patrick at stwcx.xyz> writes:
>> > On Fri, Sep 25, 2015 at 10:59:08AM +1000, Stewart Smith wrote:
>> >> +{
>> >> + lock(&occ_lock);
>> >> + occ_opal_msg_outstanding = false;
>> >> + unlock(&occ_lock);
>> >> +}
>> >
>> > ...
>> >
>> >> + if (!rc) {
>> >> chip->throttle = occ_data->throttle;
>> >> + occ_opal_msg_outstanding = true;
>> >> + break;
>> >
>> > Are you sure you don't want these to be ++ / -- ? With this current
>> > implementation you can still run out of memory if a two or more socket
>> > system is throwing excessive throttles from both OCCs.
>>
>> It's run from a poller, so we only start iterating through the memory
>> regions every so often (maybe even only once/second). If we had an
>> interrupet (like we'd like) then it'd be a bit more of an issue, but with
>> this patch, we still wouldn't have more than one outstanding message to
>> linux as we won't poll for a change until after linux has acked the
>> previous one.
>>
>
> Line 348 has a 'for_each_chip', so you send a throttled message per
> socket in the worst case. You clear the boolean when you get one
> response. Can't this end up in a 2:1 ratio of sent:recv messages under
> load?
We break out of the loop at line 372 if we successfully queued a message
More information about the Skiboot
mailing list