Re: [PATCH -mm 1/5] memcg: replace res_counter

KAMEZAWA Hiroyuki
2008-10-21T02:51:14Z

On Mon, 20 Oct 2008 19:15:37 -0700
"Paul Menage" <menage@google.com> wrote:

> On Mon, Oct 20, 2008 at 6:49 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> >
> > res_counter's operation is very short.
> > take a lock => add and compare. => unlock.
> >
> > So, I wonder there is not enough runway to do prefetch.
>
> Sorry, let me be clearer. I'm assuming that since a write operation on
> the base counter will generally be accompanied by a write operation on
> the aggregate counter, that one of the following is true:
>
That's not true. Mem+Swap contoller has following ops.

charge: page++
compare page < mem_limit.
compare page+swap < memsw_limit.
unmap/cache delete:
page--
swapout:
page--
swap++
swap_free:
swap--

....there is no *aggregate* counter. just have limit of total.

But Ok, to get Ack, I'll have to do something.

2 coutner version will be..

charge: page++ compare page < mem_limit.
memsw++ counrare memsw < memsw_limit
unmap/cache-delete:
page--
swapout:
no change.
swap_free:
memsw--

No need for *aggregate* counter. just call charge twice.

> - neither cache line is in a M or E state in our cache. So the
> prefetchw on the aggregate counter proceeds in parallel to the stall
> on fetching the base counter, and there's no additional delay to
> access the aggregate counter.
>

CPU 0 CPU1
prefetchw()
prefetchw()
spinlock()
spinlock()
win-spinlock
cache-miss.
cache-miss.

Mem+Swap counter will rerely see this. But if you want to use aggregate counter
for parent/child, you'll see *prefetchw* is no help.
parent is busier than child.

> - both cache lines are in a M or E state in our cache, so there are no
> misses on either counter.
>
But adds cost of unnecessary prefetch.

Maybe, I'll just use 2 res_coutnters. more updates will be done later if necessary.

Thanks,
-Kame