From: Dave Jones <davej@redhat.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: akpm@osdl.org, torvalds@osdl.org, linux-kernel@vger.kernel.org,
richard.brunner@amd.com
Subject: Re: [PATCH] Mutilated form of Andi Kleen's AMD prefetch errata patch
Date: Tue, 30 Sep 2003 16:08:25 +0100 [thread overview]
Message-ID: <20030930150825.GD5507@redhat.com> (raw)
In-Reply-To: <20030930144526.GC28876@mail.shareable.org>
On Tue, Sep 30, 2003 at 03:45:26PM +0100, Jamie Lokier wrote:
> > And those people are wrong. If they want to save bloat, instead of
> > 'fixing' things by removing <1 page of .text, how about working on
> > some of the real problems like shrinking some of the growth of various
> > data structures that actually *matter*.
> How about both?
Sounds like wasted effort, in the same sense that rewriting a crap
algorithm in assembly won't be better than using a more efficient
algorithm in C.
> I'm talking about people with embedded 486s or old 486s donated. P4s
> are abundant in RAM
Mine has 256MB. Sure its a huge amount in comparison to how we kitted
out 486s a few years back, but still hardly an abundance in todays bloatware..
> but 2MB is still not unheard of in the small
> boxes, and in 2MB, 512 bytes of code (which is about the size of the
> prefetch workaround) is more significant.
I'l be *amazed* if you manage to get a 2.6 kernel to boot and function
efficiently in 2MB without config'ing away a lot of the 'growth' like
sysfs. (Sidenote: Before some loon actually tries this, by function
efficiently, I mean is actually usable for some purpose, not "it booted
to a bash prompt")
> > F00F workaround was enabled on every kernel that is possible
> > to boot on affected hardware last time I looked.
> > This is what you seem to be missing, it's not optional.
> > If its possible to boot that kernel on affected hardware,
> > it needs errata workarounds.
>
> We have a few confusing issues here.
>
> 1. First, your point about affected hardware.
>
> - I don't see anything that prevents a PPro-compiled kernel from booting
> on a P5MMX with the F00F erratum.
Compiled with -m686 - Uses CMOV, won't boot.
> - Nor do I see anything that prevents a PII-compiled kernel from booting
> on a PPro with the store ordering erratum (X86_PPRO_FENCE).
Correct. As noted in another mail, it arguably should contain the
workaround.
> Perhaps it's this apparent hypocrisy which needs healing.
Agreed.
> 2. I'm not sure if you're criticising the other chap who wants
> rid of the AMD errata workaround, or my X86_PREFETCH_FIXUP code.
My criticism was twofold.
1. The splitting of X86_FEATURE_XMM into X86_FEATURE_XMM_PREFETCH and
X86_FEATURE_3DNOW_PREFETCH doesn't seem to really buy us anything
other than complication.
2. THis chunk...
+ /* Prefetch works ok? */
+#ifndef CONFIG_X86_PREFETCH_FIXUP
+ if (c->x86_vendor != X86_VENDOR_AMD || c->x86 < 6)
+#endif
+ {
+ if (cpu_has(c, X86_FEATURE_XMM))
+ set_bit(X86_FEATURE_XMM_PREFETCH, c->x86_capability);
+ if (cpu_has(c, X86_FEATURE_3DNOW))
+ set_bit(X86_FEATURE_3DNOW_PREFETCH, c->x86_capability);
+ }
- If we haven't set CONFIG_X86_PREFETCH_FIXUP (say a P4 kernel), this
code path isn't taken, and we end up not doing prefetches on P4's too
as you're not setting X86_FEATURE_XMM_PREFETCH anywhere else, and apply_alternatives
leaves them as NOPs.
- Newer C3s are 686's with prefetch, this nobbles them too.
> In case you hadn't fully grokked it, my code doesn't disable the
> workaround! It simply substitutes it for a smaller, slightly
> slower one, on kernels which are not optimised for AMD.
See above. Or have I missed something ?
> Given that, I'm not sure what the thrust of your argument is.
It's possible I'm missing something silly..
Dave
--
Dave Jones http://www.codemonkey.org.uk
next prev parent reply other threads:[~2003-09-30 15:08 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-30 7:38 [PATCH] Mutilated form of Andi Kleen's AMD prefetch errata patch Jamie Lokier
2003-09-30 8:01 ` Nick Piggin
2003-09-30 13:22 ` Dave Jones
2003-09-30 13:39 ` Jamie Lokier
2003-09-30 13:53 ` Dave Jones
2003-09-30 14:45 ` Jamie Lokier
2003-09-30 15:08 ` Dave Jones [this message]
2003-09-30 16:54 ` Jamie Lokier
2003-09-30 17:26 ` Dave Jones
2003-09-30 23:55 ` Jamie Lokier
2003-10-01 0:27 ` Andrew Morton
[not found] <20030930073814.GA26649@mail.jlokier.co.uk.suse.lists.linux.kernel>
[not found] ` <20030930132211.GA23333@redhat.com.suse.lists.linux.kernel>
[not found] ` <20030930133936.GA28876@mail.shareable.org.suse.lists.linux.kernel>
[not found] ` <20030930135324.GC5507@redhat.com.suse.lists.linux.kernel>
[not found] ` <20030930144526.GC28876@mail.shareable.org.suse.lists.linux.kernel>
[not found] ` <20030930150825.GD5507@redhat.com.suse.lists.linux.kernel>
[not found] ` <20030930165450.GF28876@mail.shareable.org.suse.lists.linux.kernel>
[not found] ` <20030930172618.GE5507@redhat.com.suse.lists.linux.kernel>
2003-09-30 19:08 ` Andi Kleen
2003-09-30 20:08 ` H. Peter Anvin
2003-10-01 1:54 Nakajima, Jun
2003-10-01 2:07 ` Andrew Morton
2003-10-01 2:08 ` Mike Fedyk
2003-10-01 2:23 Nakajima, Jun
2003-10-01 2:51 ` Jamie Lokier
2003-10-01 3:14 ` Andrew Morton
2003-10-01 4:30 Nakajima, Jun
2003-10-01 5:38 ` Jamie Lokier
2003-10-01 5:48 ` Andrew Morton
2003-10-01 6:13 ` Jamie Lokier
2003-10-01 6:32 ` Andrew Morton
2003-10-01 6:57 ` Jamie Lokier
[not found] <7F740D512C7C1046AB53446D3720017304AFCF@scsmsx402.sc.intel.com.suse.lists.linux.kernel>
[not found] ` <20031001053833.GB1131@mail.shareable.org.suse.lists.linux.kernel>
[not found] ` <20030930224853.15073447.akpm@osdl.org.suse.lists.linux.kernel>
[not found] ` <20031001061348.GE1131@mail.shareable.org.suse.lists.linux.kernel>
[not found] ` <20030930233258.37ed9f7f.akpm@osdl.org.suse.lists.linux.kernel>
2003-10-01 6:47 ` Andi Kleen
2003-10-01 7:00 ` Andrew Morton
2003-10-01 7:06 ` Andi Kleen
2003-10-01 7:31 ` Jamie Lokier
2003-10-01 7:41 ` Andi Kleen
2003-10-01 8:02 ` Hugh Dickins
2003-10-01 8:49 ` Andi Kleen
2003-10-01 9:33 ` Jamie Lokier
2003-10-01 14:51 ` Andrew Morton
2003-10-01 14:56 ` Andi Kleen
2003-10-01 15:19 ` Andrew Morton
2003-10-01 15:24 ` Andi Kleen
2003-10-01 16:18 ` Jamie Lokier
2003-10-01 7:20 ` Jamie Lokier
2003-10-01 7:39 ` Andi Kleen
2003-10-01 8:20 ` Jamie Lokier
[not found] ` <20031001065705.GI1131@mail.shareable.org.suse.lists.linux.kernel>
2003-10-01 7:15 ` Andi Kleen
2003-10-01 7:24 ` Andi Kleen
2003-10-01 7:55 ` Jamie Lokier
2003-10-01 8:00 ` Andi Kleen
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=20030930150825.GD5507@redhat.com \
--to=davej@redhat.com \
--cc=akpm@osdl.org \
--cc=jamie@shareable.org \
--cc=linux-kernel@vger.kernel.org \
--cc=richard.brunner@amd.com \
--cc=torvalds@osdl.org \
/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;
as well as URLs for NNTP newsgroup(s).