On Fri, Jan 15, 2021 at 01:24:10PM +0000, Christoph Lameter wrote:

On Thu, 14 Jan 2021, Marcelo Tosatti wrote:

quoted

quoted

How does one do a oneshot flush of OS activities?

        ret = prctl(PR_TASK_ISOLATION_REQUEST, ISOL_F_QUIESCE, 0, 0, 0);
        if (ret == -1) {
                perror("prctl PR_TASK_ISOLATION_REQUEST");
                exit(0);
        }

quoted

I.e. I have a polling loop over numerous shared and I/o devices in user
space and I want to make sure that the system is quite before I enter the
loop.

You could configure things in two ways: with syscalls allowed or not.

Well syscalls that do not cause deferred processing like getting the time
or determining the current cpu should be ok to use.

Yes.

And I already said that I want the system to quiet down and allow system
calls. 

Also see that as being useful.

Some indication that deferred actions have occurred may be useful
by f.e. resetting the flag.

OK: will implement on next patchset.

quoted

1) Add a new isolation feature ISOL_F_BLOCK_SYSCALLS (to block certain
syscalls) along with ISOL_F_SETUP_NOTIF (to notify upon isolation
breaking):

Well come up with a use case for that .... I know mine. 

Trying to come up with an interface that accomodates all known use
cases. Maybe passing the allowed list of syscalls is overkill,
but Alex seems interested in the notification to break isolation.

What you propose
could be  useful for debugging for me but I would prefer the quiet down
approach where I determine when I use some syscalls or not and will deal
with the consequences.

Trying to cover the usecases that Alex mentioned on this thread...

quoted

quoted

Features that I think may be needed:

F_ISOL_QUIESCE		-> quiet down now but allow all OS activities. OS
			activites reset flag

F_ISOL_BAREMETAL_HARD	-> No OS interruptions. Fault on syscalls that
			require such actions in the future.

Question: why BAREMETAL ?

To disinguish it from "Realtime". We want the processor for ourselves
without anything else running on it.

OK.

quoted

Two comments:

1) HARD mode could also block activities from different CPUs that can
interrupt this isolated CPU (for example CPU hotplug, or increasing
per-CPU trace buffer size).

Blocking? 

Block CPU hotplug for example: 

# echo 0 > /sys/devices/system/cpu/cpu3/online
returns -EBUSY with message saying:

"Can't offline cpu3: reason: cpu9 is isolated by application APP".

The app should fail if any deferred actions are triggered as a
result of syscalls. It would give a warning with _WARN

quoted

2) For a type of application it is the case that certain interruptions
can be tolerated, as long as they do not cross certain thresholds.
For example, one loses the flexibility to read/write MSRs
on the isolated CPUs (including performance counters,
RDT/MBM type MSRs, frequency/power statistics) by
forcing a "no interruptions" mode.

Does reading these really cause deferred actions by the OS? AFAICT you
could map these into memory as well as read them without OS activities.

AFAIK you can't for MSRs.

"Interruptions that can be tolerated".... Well that is the wild west of
"realtime" where you can define how much of a time slice is "real" and how
much can be use by other processes. I do not think that any of that should
come into this API.

Understood.