linux-kernel - Re: [MM] Make mm counters per cpu instead of atomic V2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20091106101106.8115e0f1.kamezawa.hiroyu@jp.fujitsu.com>
Date:	Fri, 6 Nov 2009 10:11:06 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	Dave Jones <davej@...hat.com>,
	"hugh.dickins@...cali.co.uk" <hugh.dickins@...cali.co.uk>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, Tejun Heo <tj@...nel.org>
Subject: Re: [MM] Make mm counters per cpu instead of atomic V2

On Thu, 5 Nov 2009 10:36:06 -0500 (EST)
Christoph Lameter <cl@...ux-foundation.org> wrote:

> From: Christoph Lameter <cl@...ux-foundation.org>
> Subject: Make mm counters per cpu V2
> 
> Changing the mm counters to per cpu counters is possible after the introduction
> of the generic per cpu operations (currently in percpu and -next).
> 
> With that the contention on the counters in mm_struct can be avoided. The
> USE_SPLIT_PTLOCKS case distinction can go away. Larger SMP systems do not
> need to perform atomic updates to mm counters anymore. Various code paths
> can be simplified since per cpu counter updates are fast and batching
> of counter updates is no longer needed.
> 
> One price to pay for these improvements is the need to scan over all percpu
> counters when the actual count values are needed.
> 
> V1->V2
> - Remove useless and buggy per cpu counter initialization.
>   alloc_percpu already zeros the values.
> 
> Signed-off-by: Christoph Lameter <cl@...ux-foundation.org>
> 
Thanks. My small concern is read-side.

This is the result of 'top -b -n 1' with 2000 processes(most of them just sleep)
on my 8cpu, SMP box.

== [Before]
 Performance counter stats for 'top -b -n 1' (5 runs):

     406.690304  task-clock-msecs         #      0.442 CPUs    ( +-   3.327% )
             32  context-switches         #      0.000 M/sec   ( +-   0.000% )
              0  CPU-migrations           #      0.000 M/sec   ( +-   0.000% )
            718  page-faults              #      0.002 M/sec   ( +-   0.000% )
      987832447  cycles                   #   2428.955 M/sec   ( +-   2.655% )
      933831356  instructions             #      0.945 IPC     ( +-   2.585% )
       17383990  cache-references         #     42.745 M/sec   ( +-   1.676% )
         353620  cache-misses             #      0.870 M/sec   ( +-   0.614% )

    0.920712639  seconds time elapsed   ( +-   1.609% )

== [After]
 Performance counter stats for 'top -b -n 1' (5 runs):

     675.926348  task-clock-msecs         #      0.568 CPUs    ( +-   0.601% )
             62  context-switches         #      0.000 M/sec   ( +-   1.587% )
              0  CPU-migrations           #      0.000 M/sec   ( +-   0.000% )
           1095  page-faults              #      0.002 M/sec   ( +-   0.000% )
     1896320818  cycles                   #   2805.514 M/sec   ( +-   1.494% )
     1790600289  instructions             #      0.944 IPC     ( +-   1.333% )
       35406398  cache-references         #     52.382 M/sec   ( +-   0.876% )
         722781  cache-misses             #      1.069 M/sec   ( +-   0.192% )

    1.190605561  seconds time elapsed   ( +-   0.417% )

Because I know 'ps' related workload is used in various ways, "How this will
be in large smp" is my concern.

Maybe usual use of 'ps -elf' will not read RSS value and not affected by this.
If this counter supports single-thread-mode (most of apps are single threaded),
impact will not be big.

Thanks,
-Kame

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/