Re: Cgroup memory barrier usage and call frequency from scheduler

From: Tejun Heo
Date: Thu Apr 09 2020 - 15:30:44 EST


Hello,

On Thu, Apr 09, 2020 at 07:20:55PM +0100, Mel Gorman wrote:
> > Given
> >
> > A C
> > --- ---
> > B D
> >
> > the code is trying to guarantee that either B sees C or D sees A, so it does
> > need full ordering.
> >
>
> Ok, still not particularly clear given where they are used and how
> it's related to updated_children but like you say later it's "kinda
> irrelevant" :)

Hahaha, yeah, just to make sure that I am understanding it correctly:

There are two parties - "updater" updating the local stat and trying to queue
itself on the updated list, "reader" walking the updated list trying to
collect all the numbers which changed since it last walked it.

There are two misbehaviors which can result from lack of interlocking:

1. If the updater puts itself on the list and the reader takes it off the list
and then reads a stale value, the reader may end up reporting a stale value
to user possibly breaking synchronity of events. This can be addressed by
adding matching (data-dependency) barriers - wmb in updater, rmb in reader.

2. If the updater checking whether it's already on the list races against
reader clearing it from the updated list, while the current on-going read
is correct, the updater may incorrectly skip adding itself to the updated
list and the next read may miss the event. This can be addressed by
interlocking both directions - either the reader sees the new value or the
updater sees itself cleared off the updated list - mb between stat update
and "am I already on the updated list?" check in updater, mb between
clearing the updater off the updated list and reading the stats in reader.

Thanks.

--
tejun