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] [day] [month] [year] [list]
Date:	Wed, 24 Apr 2013 01:09:14 -0500
From:	Rob Landley <rob@...dley.net>
To:	Ren Zhen <darwin.xupt@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [HELP] Documentation on
 CPU:/sys/devices/system/cpu/cpuX/cache/indexX/shared_cpu_map

On 04/23/2013 08:07:44 AM, Ren Zhen wrote:
> Hi all:
>     Can anybody help me to understand the usage of 'shared_cpu_map' in
> /sys/devices/system/cpu/cpuX/cache/indexX/.
>     when I execute the cmd--'#cat shared_cpu_map', it retures '05'.
>      And my computer use Ubuntu12.04,Intel core i3 CPU.
>      I have read one email in LKML,it says:
> 
> "The patch also adds a bunch of interfaces under
> /sys/devices/system/cpu/cpuX/cache, showing various information about  
> the
> caches.  Most useful field being shared_cpu_map, which says what  
> caches are
> shared among which logical cpus. "
> 
>      But I still cannot catch the meaning of  'which says what caches
> are shared among which logical cpus'.

Sounds like it means the L2 cache would be a communal resource shared  
between processors on die. So either processor could fault in cache  
lines into that pool of memory, evicting other cache lines as necessary  
to make space. So if only one processor was running, it could act like  
it had twice as much L2 cache because the memory it faulted in would  
(statistically speaking) stay in L2 cache longer before being evicted  
to make way for other memory accesses.

At a guess, the bits set (1<<0 and 1<<2 in this case) indicate which  
cpus access memory through the same pool of L2 cache.

Rob--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ