All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Rohit Seth <rohit.seth@intel.com>
Subject: Re: [PATCH] Reading deterministic cache parameters and exporting it in /sysfs
Date: Tue, 15 Mar 2005 18:36:20 -0500	[thread overview]
Message-ID: <20050315233620.GC14380@redhat.com> (raw)
In-Reply-To: <20050315152448.A1697@unix-os.sc.intel.com>

On Tue, Mar 15, 2005 at 03:24:48PM -0800, Venkatesh Pallipadi wrote:
 >  
 > The attached patch adds support for using cpuid(4) instead of cpuid(2), to get 
 > CPU cache information in a deterministic way for Intel CPUs, whenever 
 > supported. The details of cpuid(4) can be found here
 > 
 > IA-32 Intel Architecture Software Developer's Manual (vol 2a)
 > (http://developer.intel.com/design/pentium4/manuals/index_new.htm#sdm_vol2a)
 > and
 > Prescott New Instructions (PNI) Technology: Software Developer's Guide
 > (http://www.intel.com/cd/ids/developer/asmo-na/eng/events/43988.htm)
 >  
 > The advantage of using the cpuid(4) ('Deterministic Cache Parameters Leaf') are:
 > * It provides more information than the descriptors provided by cpuid(2)
 > * It is not table based as cpuid(2). So, we will not need changes to the 
 >   kernel to support new cache descriptors in the descriptor table (as is the 
 >   case with cpuid(2)).
 >  
 > The patch also adds a bunch of interfaces under 
 > /sys/devices/system/cpu/cpuX/cache, showing various information about the
 > caches.

Why does this need to be in kernel-space ? Is there some reason that prevents
you from enhancing x86info for example ?  I really want to live to see the
death of /proc/cpuinfo one day, and reinventing it in sysfs seems pointless
if it can all be done in userspace.
 
 > Most useful field being shared_cpu_map, which says what caches are 
 > shared among which logical cpus. 

Given that the most useful field is of limited use to a majority of users,
and those that are interested can read this from userspace, this has me very puzzled.

		Dave


  reply	other threads:[~2005-03-15 23:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-15 23:24 [PATCH] Reading deterministic cache parameters and exporting it in /sysfs Venkatesh Pallipadi
2005-03-15 23:36 ` Dave Jones [this message]
2005-03-16  0:10   ` Venkatesh Pallipadi
2005-03-16 10:29   ` Daniel Egger
2005-03-16  7:07 ` Andrew Morton
2005-03-18 19:18   ` Venkatesh Pallipadi
2005-03-18 19:46     ` Dave Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050315233620.GC14380@redhat.com \
    --to=davej@redhat.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rohit.seth@intel.com \
    --cc=torvalds@osdl.org \
    --cc=venkatesh.pallipadi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.