Re: [RFC] Reduce the resource counter lock overhead

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Thu, 25 Jun 2009 08:57:17 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> > What kind of workload can be much improved ?
> > IIUC, in general, using seq_lock to frequently modified counter just makes
> > it slow.
> 
> Why do you think so? I've been looking primarily at do_gettimeofday().
IIUC, modification to xtime is _not_ frequent.

> Yes, frequent updates can hurt readers in the worst case. 
You don't understand my point. write-side of seqlock itself is
heavy. I have no interests in read-side.

What need to be faster is here.
==
 929         while (1) {
 930                 int ret;
 931                 bool noswap = false;
 932 
 933                 ret = res_counter_charge(&mem->res, PAGE_SIZE, &fail_res);
 934                 if (likely(!ret)) {
 935                         if (!do_swap_account)
 936                                 break;
 937                         ret = res_counter_charge(&mem->memsw, PAGE_SIZE,
 938                                                         &fail_res);
 939                         if (likely(!ret))
 940                                 break;
 941                         /* mem+swap counter fails */
 942                         res_counter_uncharge(&mem->res, PAGE_SIZE);
 943                         noswap = true;
 944                         mem_over_limit = mem_cgroup_from_res_counter(fail_res,
 945                                                                         memsw);
 946                 } else
 947                         /* mem counter fails */
 948                         mem_over_limit = mem_cgroup_from_res_counter(fail_res,
 949                                              
==
And using seq_lock will add more overheads to here.

> I've been
> meaning to experiment with percpu counters as well, but we'll need to
> decide what is the tolerance limit, since we can have a batch value
> fuzziness, before all CPUs see that the limit is exceeded, but it
> might be worth experimenting.
> 

per-cpu counter is a choice. but "batch" value is very difficult if
we never allow "exceeds". And if # of bactch is too small, percpu
counter is slower than current one.
And if hierarchy is used, jitter by batch will be very big in parent nodes.



Thanks,
-Kame

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>