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-next>] [day] [month] [year] [list]
Message-Id: <1389209168-17189-1-git-send-email-sudeep.holla@arm.com>
Date:	Wed,  8 Jan 2014 19:26:05 +0000
From:	Sudeep Holla <sudeep.holla@....com>
To:	x86@...nel.org, linuxppc-dev@...ts.ozlabs.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Cc:	sudeep.holla@....com, Ashok Raj <ashok.raj@...el.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Rob Herring <robh@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: [PATCH RFC 0/3] drivers: cacheinfo support

From: Sudeep Holla <sudeep.holla@....com>

Hi,

This series adds a generic cacheinfo support similar to topology. The
implementation is based on x86 cacheinfo support. Currently x86 and
powerpc have their own implementations. While adding similar support
to ARM, here is the attempt to make it generic quite similar to topology
info support.

This series also adds support for ARM architecture based on the generic
support. ARM uses device tree for cache hierarcy as there is no 
architectural way of getting it. On non-DT platforms, first level caches
are per-cpu while higher level caches are assumed system-wide.

I can move the x86 and powerpc implementations to use this generic one
based on the feedback. However I have few open questions:

1. Do we need to populate cache data on hotplug path or just once
   during the boot on all cpus will suffice ? Hotplug path seems more
   appropriate for me but based on my understanding(I may be wrong here)
   of x86 code, I placed it in boot patch for now. I can change it.

2. I see some custom/arch specific sysfs entries(e.g. AMD L3 cache
   partitioning feature). How do we deal with that ?

I had posted previous version[1] without generic implementation(ARM 
specific)

Regards,
Sudeep

[1] https://lkml.org/lkml/2013/9/18/340

Sudeep Holla (3):
  drivers: base: support cpu cache information interface to userspace
    via sysfs
  ARM: kernel: add support for cpu cache information
  ARM: kernel: add outer cache support for cacheinfo implementation

 arch/arm/include/asm/cacheinfo.h  |   7 +
 arch/arm/include/asm/outercache.h |  13 ++
 arch/arm/kernel/Makefile          |   1 +
 arch/arm/kernel/cacheinfo.c       | 438 ++++++++++++++++++++++++++++++++++++++
 arch/arm/kernel/setup.c           |   2 +
 arch/arm/mm/Kconfig               |  13 ++
 arch/arm/mm/cache-l2x0.c          |  14 ++
 arch/arm/mm/cache-tauros2.c       |  35 +++
 arch/arm/mm/cache-xsc3l2.c        |  15 ++
 drivers/base/Makefile             |   2 +-
 drivers/base/cacheinfo.c          | 296 ++++++++++++++++++++++++++
 include/linux/cacheinfo.h         |  43 ++++
 12 files changed, 878 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/include/asm/cacheinfo.h
 create mode 100644 arch/arm/kernel/cacheinfo.c
 create mode 100644 drivers/base/cacheinfo.c
 create mode 100644 include/linux/cacheinfo.h

-- 
1.8.3.2

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