On 7/12/19 3:07 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 02:47:23PM +0200, Alexandre Chartre wrote:
On 7/12/19 2:36 PM, Peter Zijlstra wrote:
On Fri, Jul 12, 2019 at 02:17:20PM +0200, Alexandre Chartre wrote:
On 7/12/19 1:44 PM, Peter Zijlstra wrote:
AFAIK3 this wants/needs to be combined with core-scheduling to be
useful, but not a single mention of that is anywhere.
No. This is actually an alternative to core-scheduling. Eventually, ASI
will kick all sibling hyperthreads when exiting isolation and it needs to
run with the full kernel page-table (note that's currently not in these
patches).
So ASI can be seen as an optimization to disabling hyperthreading: instead
of just disabling hyperthreading you run with ASI, and when ASI can't preserve
isolation you will basically run with a single thread.
You can't do that without much of the scheduler changes present in the
core-scheduling patches.
We hope we can do that without the whole core-scheduling mechanism. The idea
is to send an IPI to all sibling hyperthreads. This IPI will interrupt these
sibling hyperthreads and have them wait for a condition that will allow them
to resume execution (for example when re-entering isolation). We are
investigating this in parallel to ASI.
You cannot wait from IPI context, so you have to go somewhere else to
wait.
Also, consider what happens when the task that entered isolation decides
to schedule out / gets migrated.
I think you'll quickly find yourself back at core-scheduling.
I haven't looked at details about what has been done so far. Hopefully, we
can do something not too complex, or reuse a (small) part of co-scheduling.
Thanks for pointing this out.
alex.
