On Wed, 29 May 2013 14:20:12 -0700 Tim Chen wrote:
> > Do we have any performance testing results? They're pretty important
> > for a performance-improvement patch ;)
> >
>
> I've done a repeated brk test of 800KB (from will-it-scale test suite)
> with 80 concurrent processes on a 4 socket Wes
On Wed, 2013-05-29 at 12:26 -0700, Andrew Morton wrote:
> On Wed, 22 May 2013 16:37:18 -0700 Tim Chen
> wrote:
>
> > Currently the per cpu counter's batch size for memory accounting is
> > configured as twice the number of cpus in the system. However,
> > for system with very large memory, it i
On Wed, 22 May 2013 16:37:18 -0700 Tim Chen wrote:
> Currently the per cpu counter's batch size for memory accounting is
> configured as twice the number of cpus in the system. However,
> for system with very large memory, it is more appropriate to make it
> proportional to the memory size per c
On Wed, 2013-05-22 at 00:20 -0700, Andrew Morton wrote:
> > +#ifdef CONFIG_SMP
> > +extern int vm_committed_as_batch;
> > +
> > +static inline void mm_compute_batch(void)
> > +{
> > +int nr = num_present_cpus();
> > +int batch = max(32, nr*2);
> > +
> > +/* batch size set t
On Tue, 21 May 2013 17:43:10 -0700 Tim Chen wrote:
>
> I'll spin off another version of the patch later to add the
> memory-hotplug notifier. In the mean time, does the following looks
> good to you?
>
> ...
>
> --- a/include/linux/mman.h
> +++ b/include/linux/mman.h
> @@ -10,12 +10,30 @@
> e
On Tue, 2013-05-21 at 16:41 -0700, Andrew Morton wrote:
> I think we could use __percpu_counter_add() unconditionally here and
> just do
>
> #ifdef CONFIG_SMP
> #define vm_committed_as_batch 0
> #else
> int vm_committed_as_batch;
> #endif
>
> The EXPORT_SYMBOL(vm_committed_as_batch) is unneeded.
On Tue, 21 May 2013 16:27:29 -0700 Tim Chen wrote:
> Will something like the following work if we get rid of the percpu
> counter changes and use __percpu_counter_add(..., batch)? In
> benchmark with a lot of memory changes via brk, this makes quite
> a difference when we go to a bigger batch si
On Tue, 2013-05-21 at 13:41 -0700, Andrew Morton wrote:
> This patch seems to add rather a lot of unnecessary code.
>
> - The increase in the size of percu_counter is regrettable.
>
> - The change to percpu_counter_startup() is unneeded - no
> percpu_counters should exist at this time. (We ma
On Fri, 3 May 2013 03:10:52 -0700 Tim Chen wrote:
> Currently, there is a single, global, variable (percpu_counter_batch) that
> controls the batch sizes for every 'struct percpu_counter' on the system.
>
> However, there are some applications, e.g. memory accounting where it is
> more appropri
Currently, there is a single, global, variable (percpu_counter_batch) that
controls the batch sizes for every 'struct percpu_counter' on the system.
However, there are some applications, e.g. memory accounting where it is
more appropriate to scale the batch size according to the memory size.
This
10 matches
Mail list logo
