Ming,
Ming Lei <ming.lei@xxxxxxxxxx> writes:
> On Fri, Jan 10, 2020 at 08:43:14PM +0100, Thomas Gleixner wrote:
>> Ming Lei <ming.lei@xxxxxxxxxx> writes:
>> > That is why I try to exclude isolated CPUs from interrupt effective affinity,
>> > turns out the approach is simple and doable.
>>
>> Yes, it's doable. But it still is inconsistent behaviour. Assume the
>> following configuration:
>>
>> 8 CPUs CPU0,1 assigned for housekeeping
>>
>> With 8 queues the proposed change does nothing because each queue is
>> mapped to exactly one CPU.
>
> That is expected behavior for this RT case, given userspace won't submit
> IO from isolated CPUs.
What is _this_ RT case? We really don't implement policy for a specific
use case. If the kernel implements a policy then it has to be generally
useful and practical.
>> With 4 queues you get the following:
>>
>> CPU0,1 queue 0
>> CPU2,3 queue 1
>> CPU4,5 queue 2
>> CPU6,7 queue 3
>>
>> No effect on the isolated CPUs either.
>>
>> With 2 queues you get the following:
>>
>> CPU0,1,2,3 queue 0
>> CPU4,5,6,7 queue 1
>>
>> So here the isolated CPUs 2 and 3 get the isolation, but 4-7
>> not. That's perhaps intended, but definitely not documented.
>
> That is intentional change, given no IO will be submitted from 4-7
> most of times in RT case, so it is fine to select effective CPU from
> isolated CPUs in this case. As peter mentioned, IO may just be submitted
> from isolated CPUs during booting. Once the system is setup, no IO
> comes from isolated CPUs, then no interrupt is delivered to isolated
> CPUs, then meet RT's requirement.
Again. This is a specific usecase. Is this generally applicable?
> We can document this change somewhere.
Yes, this needs to be documented very clearly with that command line
parameter.
>> So you really need to make your mind up and describe what the intended
>> effect of this is and why you think that the result is correct.
>
> In short, if there is at least one housekeeping available in the
> interrupt's affinity, we choose effective CPU from housekeeping CPUs.
> Otherwise, keep the current behavior wrt. selecting effective CPU.
>
> With this approach, no interrupts can be delivered to isolated CPUs
> if no IOs are submitted from these CPUs.
>
> Please let us know if it addresses your concerns.
Mostly. See above.
Thanks,
tglx
