On Thu, 2016-03-24 at 12:44 +, George Dunlap wrote:
> On 18/03/16 19:27, Andrew Cooper wrote:
> > This avoids all this opencoded allocation/refcounting, the chance
> > that
> > starting a scheduler would fail for memory reasons, and one extra
> > cpumask in the per-cpu data area won't break the
On 24/03/16 12:44, George Dunlap wrote:
> On 18/03/16 19:27, Andrew Cooper wrote:
>> On 18/03/16 19:06, Dario Faggioli wrote:
>>> like what's there already in both Credit1 and RTDS. In
>>> fact, when playing with affinity, a lot of cpumask
>>> manipulation is necessary, inside of various functions.
On 18/03/16 19:27, Andrew Cooper wrote:
> On 18/03/16 19:06, Dario Faggioli wrote:
>> like what's there already in both Credit1 and RTDS. In
>> fact, when playing with affinity, a lot of cpumask
>> manipulation is necessary, inside of various functions.
>>
>> To avoid having a lot of cpumask_var_t
On 18/03/16 19:06, Dario Faggioli wrote:
> like what's there already in both Credit1 and RTDS. In
> fact, when playing with affinity, a lot of cpumask
> manipulation is necessary, inside of various functions.
>
> To avoid having a lot of cpumask_var_t on the stack,
> this patch introduces a global
like what's there already in both Credit1 and RTDS. In
fact, when playing with affinity, a lot of cpumask
manipulation is necessary, inside of various functions.
To avoid having a lot of cpumask_var_t on the stack,
this patch introduces a global scratch area.
Signed-off-by: Dario Faggioli
---
Cc
