public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@suse.cz>
To: Mark Langsdorf <mark.langsdorf@amd.com>
Cc: Greg KH <greg@kroah.com>,
	joachim.deguara@amd.com, gregkh@ucw.cz, tglx@linutronix.de,
	mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/01][retry 3] x86: L3 cache index disable for 2.6.26
Date: Thu, 14 Aug 2008 15:44:57 +0200	[thread overview]
Message-ID: <20080814134457.GD2262@elf.ucw.cz> (raw)
In-Reply-To: <200808140843.44090.mark.langsdorf@amd.com>

Hi!

> New versions of AMD processors have support to disable parts
> of their L3 caches if too many MCEs are generated by the
> L3 cache.  
> 
> This patch provides a /sysfs interface under the cache
> hierarchy to display which caches indices are disabled
> (if any) and to monitoring applications to disable a
> cache index.
> 
> This patch does not set an automatic policy to disable
> the L3 cache.  Policy decisions would need to be made
> by a RAS handler.  This patch merely makes it easier to
> see what indices are currently disabled.
> 
> Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com>
> 
> 
> diff -r e683983d4dd0 Documentation/ABI/testing/sysfs-devices-cache_disable
> --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
> +++ b/Documentation/ABI/testing/sysfs-devices-cache_disable	Thu Aug 14 02:54:30 2008 -0500
> @@ -0,0 +1,18 @@
> +What:           /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X
> +Date:           Augsust 2008
> +KernelVersion:  2.6.27
> +Contact:        mark.langsdorf@amd.com
> +Description:    These files exist in every cpu's cache index directories.
> +		There are currently 2 cache_disable_# files in each 
> +		directory.  Reading from these files on a supported
> +		processor will return that cache disable index value
> +		for that processor and node.  Writing to one of these
> +		files will cause the specificed cache index to be disable.
> +
> +		Currently, only AMD Family 10h Processors support cache index 
> +		disable, and only for their L3 caches.  See the BIOS and
> +		Kernel Developer's Guide at
> +		http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.PDF
> +		for formatting information and other details on the
> +		cache index disable.
> +Users:          joachim.deguara@amd.com
> diff -r e683983d4dd0 arch/x86/kernel/cpu/intel_cacheinfo.c
> --- a/arch/x86/kernel/cpu/intel_cacheinfo.c	Tue Aug 12 08:46:38 2008 -0500
> +++ b/arch/x86/kernel/cpu/intel_cacheinfo.c	Thu Aug 14 02:54:00 2008 -0500
> @@ -16,6 +16,9 @@
>  
>  #include <asm/processor.h>
>  #include <asm/smp.h>
> +
> +#include <linux/pci.h>
> +#include <asm/k8.h>
>  
>  #define LVL_1_INST	1
>  #define LVL_1_DATA	2
> @@ -130,6 +133,7 @@ struct _cpuid4_info {
>  	union _cpuid4_leaf_ebx ebx;
>  	union _cpuid4_leaf_ecx ecx;
>  	unsigned long size;
> +	unsigned long can_disable;
>  	cpumask_t shared_cpu_map;	/* future?: only cpus/node is needed */
>  };
>  
> @@ -251,6 +255,14 @@ static void __cpuinit amd_cpuid4(int lea
>  		(ebx->split.ways_of_associativity + 1) - 1;
>  }
>  
> +static void __cpuinit 
> +amd_check_l3_disable(int index, struct _cpuid4_info *this_leaf)
> +{
> +	if (index < 3)
> +		return;
> +	this_leaf->can_disable = 1;     
> +}
> +
>  static int __cpuinit cpuid4_cache_lookup(int index, struct _cpuid4_info *this_leaf)
>  {
>  	union _cpuid4_leaf_eax 	eax;
> @@ -258,10 +270,13 @@ static int __cpuinit cpuid4_cache_lookup
>  	union _cpuid4_leaf_ecx 	ecx;
>  	unsigned		edx;
>  
> -	if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
> +	if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
>  		amd_cpuid4(index, &eax, &ebx, &ecx);
> -	else
> -		cpuid_count(4, index, &eax.full, &ebx.full, &ecx.full,  &edx);
> +		if (boot_cpu_data.x86 >= 0x10)
> +			amd_check_l3_disable(index, this_leaf);
> +	} else {
> +		cpuid_count(4, index, &eax.full, &ebx.full, &ecx.full, &edx);
> +	}
>  	if (eax.split.type == CACHE_TYPE_NULL)
>  		return -EIO; /* better error ? */
>  
> @@ -269,9 +284,9 @@ static int __cpuinit cpuid4_cache_lookup
>  	this_leaf->ebx = ebx;
>  	this_leaf->ecx = ecx;
>  	this_leaf->size = (ecx.split.number_of_sets + 1) *
> -		(ebx.split.coherency_line_size + 1) *
> -		(ebx.split.physical_line_partition + 1) *
> -		(ebx.split.ways_of_associativity + 1);
> +			(ebx.split.coherency_line_size + 1) *
> +			(ebx.split.physical_line_partition + 1) *
> +			(ebx.split.ways_of_associativity + 1);
>  	return 0;
>  }
>  
> @@ -574,6 +589,9 @@ static DEFINE_PER_CPU(struct _index_kobj
>  static DEFINE_PER_CPU(struct _index_kobject *, index_kobject);

> +static ssize_t
> +store_cache_disable(struct _cpuid4_info *this_leaf, const char *buf,
> +		size_t count, unsigned int index)
> +{
> +        int node = cpu_to_node(first_cpu(this_leaf->shared_cpu_map));
> +        struct pci_dev *dev = get_k8_northbridge(node);
> +        ssize_t ret = 0;
> +        unsigned int val;
> +
> +        if (!this_leaf->can_disable)
> +                return -EINVAL;
> +
> +        if (strlen(buf) > 10)
> +                return -EINVAL;
> +
> +        ret = sscanf(buf, "%x", &val);
> +        if (ret != 1)
> +                return -EINVAL;

Is it okay to strlen() on user-supplied data? Do they have to be
null-terminated? What about sscanf?

> +        val |= 0xc0000000;
> +        pci_write_config_dword(dev, 0x1BC + index * 4, val & ~0x40000000);
> +        wbinvd();
> +        pci_write_config_dword(dev, 0x1BC + index * 4, val);

Should it do if capable() test before doing such stuff?

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2008-08-14 13:59 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-18 21:03 [PATCH 01/01] x86: L3 cache index disable for 2.6.26 Mark Langsdorf
2008-07-21 11:37 ` Ingo Molnar
2008-07-21 12:48   ` Ingo Molnar
2008-07-22 18:06     ` Mark Langsdorf
2008-07-28 14:22       ` Ingo Molnar
2008-07-28 14:49         ` Ingo Molnar
2008-07-28 14:54           ` Langsdorf, Mark
2008-08-08 22:00 ` Pavel Machek
2008-08-12 16:04   ` [PATCH 01/01][retry 1] " Mark Langsdorf
2008-08-12 21:56     ` Pavel Machek
2008-08-12 22:01       ` Langsdorf, Mark
2008-08-12 22:07         ` Pavel Machek
2008-08-12 22:53         ` Greg KH
2008-08-12 22:12       ` Greg KH
2008-08-13 20:02         ` [PATCH 01/01][retry 2] " Mark Langsdorf
2008-08-13 20:38           ` Pavel Machek
2008-08-13 23:45           ` Greg KH
2008-08-14 13:43             ` [PATCH 01/01][retry 3] " Mark Langsdorf
2008-08-14 13:44               ` Pavel Machek [this message]
2008-08-14 14:02                 ` Langsdorf, Mark
2008-08-14 15:46                   ` Pavel Machek
2008-08-14 16:41                     ` Langsdorf, Mark
2008-08-14 14:04               ` Greg KH
2008-08-14 14:23           ` [PATCH 01/01][retry 4] " Mark Langsdorf
2008-08-14 16:48             ` [PATCH 01/01][retry 5] " Mark Langsdorf
2008-08-14 17:10               ` Greg KH
2008-08-14 18:32                 ` Mark Langsdorf
2008-08-15 16:42                   ` Ingo Molnar
2008-08-15 19:21                     ` Langsdorf, Mark
2008-08-15 19:57                       ` Ingo Molnar
2008-08-15 20:02                         ` Langsdorf, Mark

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=20080814134457.GD2262@elf.ucw.cz \
    --to=pavel@suse.cz \
    --cc=greg@kroah.com \
    --cc=gregkh@ucw.cz \
    --cc=hpa@zytor.com \
    --cc=joachim.deguara@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.langsdorf@amd.com \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox