[Skiboot] [PATCH] Rate limit OPAL_MSG_OCC to only one outstanding message to host

[Stewart Smith]

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