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

From: Nick Piggin (piggin_at_cyberone.com.au)
Date: 09/30/03

  • Next message: Frédéric St-Martin: "Re: [PATCH] document optimizing macro for translating PROT_ to VM_ bits" 
    Date:	Tue, 30 Sep 2003 18:01:10 +1000
To: Jamie Lokier <jamie@shareable.org>

    Jamie Lokier wrote:

    >This builds upon Andi Kleen's excellent patch for the AMD prefetch bug
    >workaround. It is applies to 2.6.0-test6.
    >
    >There are four changes on top of Andi's recent patch:
    >
    > 1. The workaround code is only included when compiling a kernel
    > optimised for AMD processors with the bug. For kernels optimised
    > for a different processor, there is no code size overhead.
    >
    > This will make some people happier.
    >
    > It will make some people unhappier, because it means a generic
    > kernel on an AMD will run fine, but won't fixup _userspace_
    > prefetch faults. More on this below.
    >
    > 2. Nevertheless, when a kernel _not_ optimised for those AMD processors
    > is run on one, the "alternative" mechanism now correctly replaces
    > prefetch instructions with nops.
    >
    > 3. The is_prefetch() instruction decoder now handles all cases of
    > funny GDT and LDT segments, checks limits and so on. As far as I
    > can see, there are no further bugs or flaws in that part.
    >
    > 4. A consequence of the is_prefetch() change is that, despite the
    > longer C code (rarely used code, for segments), is_prefetch()
    > should run marginally faster now because the access_ok() calls are
    > not required. They're subsumed into the segment limit
    > calculation.
    >
    >Like Andi's patch, this removes 10k or so from current x86 kernels by
    >removing the silly conditional from the prefetch() function.
    >
    >Controversial point coming up!
    >

    It sounds good Jamie, but could you possibly compile it in
    unconditionally? Otherwise it introduces yet another caveat to the CPU
    selection / build system. This can be addressed seperately.

    I don't think anyone advocates attempting to handle this nicely with the
    current CPU selection system, nor were they targeting this patch in
    particular. It just kicked off a discussion about the shortfalls of the
    selection system.

    -
    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: Frédéric St-Martin: "Re: [PATCH] document optimizing macro for translating PROT_ to VM_ bits"