Re: [PATCH] Mutilated form of Andi Kleen's AMD prefetch errata patch

From: Dave Jones (davej_at_redhat.com)
Date: 09/30/03

  • Next message: David S. Miller: "Re: [PATCH 2.4] Fix bug in atm/he.c" 
    Date:	Tue, 30 Sep 2003 14:53:24 +0100
To: Jamie Lokier <jamie@shareable.org>

    On Tue, Sep 30, 2003 at 02:39:36PM +0100, Jamie Lokier wrote:
    > Dave Jones wrote:
    > > This looks to be completely gratuitous. Why disable it when we have the
    > > ability to work around it ?
    >
    > Because some people expressed a wish to have kernels that don't
    > contain the workaround code, be they P4-optimised or 486-optimised
    > kernels.

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

    The "I don't want Athlon code in my kernel because I run a P4 and
    it makes it slow/bigger" argument is totally bogus. It's akin to
    the gentoo-esque "I compiled my distro with -march=p4 and now
    my /bin/ls is faster than yours" argument.

    > After all we have kernels that don't contain the F00F
    > workaround too. I'm not pushing this patch as is, it's for
    > considering the pros and cons.

    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.

    > CONFIG_X86_PREFETCH_WORKAROUND makes more makes more sense with the
    > recently available "split every x86 CPU into individually selectable
    > options" patch, and, on reflection, that's probably where it belongs.

    Said patch isn't included in mainline, so this argument is bogus.
    Relative merits of that patch were already discussed in another thread.

                    Dave 

    -- 
 Dave Jones     http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: David S. Miller: "Re: [PATCH 2.4] Fix bug in atm/he.c"

    Relevant Pages

    • Re: RT patch acceptance
      ... judge the complexity of a design for that type of system. ... claim that you cannot judge the complexity of a kernel modification. ... Since the patch in question doesn't actually need that information to ... nanokernel's API up to date with additions to Linux's API that RT people ...
      (Linux-Kernel)
    • [RFC] Making percpu module variables have their own memory.
      ... Someone using the -rt patch found that one of the tracing options caused ... 64K for every CPU to cover all the per_cpu variables used in the kernel ... static void wakeup_softirqd_prio ...
      (Linux-Kernel)
    • Re: This is [Re:] How to improve the quality of the kernel[?].
      ... The -mm kernel already implements what your proposed PTS would do. ... If patch have no TS ID, ... Thus i can apply for example lguest patches and implement and test new ... How many open source projects use Bugzilla and how many use the Debian BTS? ...
      (Linux-Kernel)
    • Re: Documentation - how to apply patches for various trees
      ... >> explanation of the various kernel trees and how to apply their patches. ... +a patch to the kernel or, more specifically, what base kernel a patch for ... +and what new version the patch will change the source tree into. ...
      (Linux-Kernel)
    • [Full-Disclosure] Re: Buffer overflow prevention
      ... >> that may need executable stack). ... >> need to be compiled into anything but the kernel. ... the GRsec patch is a single option in the kernel ... way grsecurity gets a little to restrictive with things like restericting ...
      (Full-Disclosure)