On Wed, Nov 18, 2015 at 07:25:03PM +0100, Thomas Gleixner wrote:
>
> Let's look at partitioning itself. We have two options:
>
> 1) Per task partitioning
>
> 2) Per CPU partitioning
>
> So far we only talked about #1, but I think that #2 has a value as
> well. Let me give you a simple example.
I would second this. In practice per CPU partitioning is useful for
realtime as well. And I can see three possible solutions:
1) What you suggested below, to address both problems in one
framework. But I wonder if it would end with too complex.
2) Achieve per CPU partitioning with per task partitioning. For
example, if current CAT patch can solve the kernel threads
problem, together with CPU pinning, we then can set a same CBM
for all the tasks/kernel threads run on an isolated CPU.
3) I wonder if it feasible to separate the two requirements? For
example, divides the work into three components: rdt-base,
per task interface (current cgroup interface/IOCTL or something)
and per CPU interface. The two interfaces are exclusive and
selected at build time. One thing to reject this option would be
even with per CPU partitioning, we still need per task partitioning,
in that case we will go to option 1) again.
Thanks,
Chao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
