[Skiboot] [PATCH v2 2/2] prd: PRD framework

Stewart Smith stewart at linux.vnet.ibm.com
Thu Feb 12 18:27:53 AEDT 2015


Neelesh Gupta <neelegup at linux.vnet.ibm.com> writes:
>>> +	lock(&prd_lock);
>>> +	node = list_pop(&prd_free_list, struct prd_node, link);
>>> +	if (!node) { /* Free list exhausted */
>>> +		node = zalloc(sizeof(*node));
>>> +		if (!node) {
>>> +			prlog(PR_ERR, "Failed to allocate prd node\n");
>>> +			unlock(&prd_lock);
>>> +			return OPAL_NO_MEM;
>>> +		}
>>> +	}
>> Why not just dynamically allocate everything? Why have a free list at
>> all if we're just going to allocate until ENOMEM?
>
> Have sufficiently allocated during init() and added them to the free list to
> cater to multiple messages which should not exhaust the free list and reduce
> fragmentation, but if it does then it is not an error and we dynamically 
> allocate..
> further add and maintain it in the list.
>
>>
>> Also, I see extra allocation but nowhere where these extra ones are freed?
>
> These are not freed, added and maintained as part of the 'free' list.

This is a problem - a flood of these will hit ENOMEM and that won't be
good for keeping the system running at all (many OPAL calls would fail
without being able to allocate memory).


>>> --- a/include/platform.h
>>> +++ b/include/platform.h
>>> @@ -100,6 +100,8 @@ struct platform {
>>>   	 */
>>>   	void		(*external_irq)(unsigned int chip_id);
>>>   
>>> +	void		(*local_irq)(unsigned int chip_id);
>>> +
>>>   	/*
>>>   	 * nvram ops.
>>>   	 *
>> Why is this a platform op? It seems identical for the time being... or
>> is it just missing in rhesus?
>
> Is not the prd interrupts platform dependent? they reach to OPAL thru 
> same channel
> but could be of different nature between the platforms..?

Let's change it to a platform op when/if there's something that needs to
be platform specific.



More information about the Skiboot mailing list