[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen/sched: rework credit2 run-queue allocation



On 19.02.2020 17:47, Dario Faggioli wrote:
> On Thu, 2020-01-23 at 09:55 +0100, Juergen Gross wrote:
>> --- a/xen/common/sched/credit2.c
>> +++ b/xen/common/sched/credit2.c
>> @@ -849,51 +822,71 @@ static inline bool same_core(unsigned int cpua,
>> unsigned int cpub)
>>             cpu_to_core(cpua) == cpu_to_core(cpub);
>>  }
>>  
>> -static unsigned int
>> -cpu_to_runqueue(const struct csched2_private *prv, unsigned int cpu)
>> +static struct csched2_runqueue_data *
>> +cpu_add_to_runqueue(struct csched2_private *prv, unsigned int cpu)
>>  {
>> -    const struct csched2_runqueue_data *rqd;
>> -    unsigned int rqi;
>> +    struct csched2_runqueue_data *rqd, *rqd_new;
>> +    struct list_head *rqd_ins;
>> +    unsigned long flags;
>> +    int rqi = 0;
>> +    bool rqi_unused = false, rqd_valid = false;
>> +
>> +    rqd_new = xzalloc(struct csched2_runqueue_data);
>>  
>>
> So, I'm not sure I see why it's better to allocating this here, and
> then free it if we didn't need it, instead than allocating it later,
> only if we actually need it... What am I missing? :-)

Where possible we should try to avoid calling allocation functions
with locks held.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.