Re: [PATCH v16 00/13] support "task_isolation" mode

[Chris Metcalf]

On 11/7/2017 12:10 PM, Christopher Lameter wrote:
> On Mon, 6 Nov 2017, Chris Metcalf wrote:
>
> > On 11/6/2017 10:38 AM, Christopher Lameter wrote:
> > > > What about that d*mn 1 Hz clock?
> > > >
> > > > It's still there, so this code still requires some further work before
> > > > it can actually get a process into long-term task isolation (without
> > > > the obvious one-line kernel hack).  Frederic suggested a while ago
> > > > forcing updates on cpustats was required as the last gating factor; do
> > > > we think that is still true?  Christoph was working on this at one
> > > > point - any progress from your point of view?
> > > Well if you still have the 1 HZ clock then you can simply defer the numa
> > > remote page cleanup of the page allocator to that the time you execute
> > > that tick.
> > We have to get rid of the 1 Hz tick, so we don't want to tie anything
> > else to it...
> Yes we want to get rid of the 1 HZ tick but the work on that could also
> include dealing with the remove page cleanup issue that we have deferred.
>
> Presumably we have another context there were we may be able to call into
> the cleanup code with interrupts enabled.

Right now for task isolation we run with interrupts enabled during the
initial sys_prctl() call, and call quiet_vmstat_sync() there, which 
currently
calls refresh_cpu_vm_stats(false). In fact we could certainly pass "true"
there instead (and probably should) since we can handle dealing with
the pagesets at this time. As we return to userspace we will test that
nothing surprising happened with vmstat; if so we jam an EAGAIN into
the syscall result value, but if not, we will be in userspace and won't need
to touch the vmstat counters until we next go back into the kernel.

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com