Re: your mail

From: Jamie Lokier (jamie_at_shareable.org)
Date: 09/30/03

  • Next message: Dave Jones: "Re: [PATCH] Mutilated form of Andi Kleen's AMD prefetch errata patch" 
    Date:	Tue, 30 Sep 2003 15:58:54 +0100
To: John Bradford <john@grabjohn.com>

    John Bradford wrote:
    > Unless, of course, you object to the possibility that somebody might
    > go out of their way to compile a 386 specific kernel from source
    > themselves, then run it on an Athlon. By chance it will probably
    > appear to work OK, but won't have the workaround enabled. So what?

    Actually the 386 kernel will work just fine on the AMD... The
    workaround is only needed, in the kernel, to protect against the
    kernel's own use of non-386 features...

    Userspace is a different matter, but userspace has a lot of
    model-specific things to worry about beyond this one instruction on
    AMD. In practice: bswap, cmov, cmpxchg, mmx, sse, sse2, so knowing
    whether to use prefetch or not is just one more variable for userspace
    - and one which any portable app or library will have to know about in
    any case.

    (Aside: It is quite an anomaly that those cumbersome floating point
    instructions are emulated on the older CPUs, yet all the other
    instructions aren't emulated. Emulation is very slow, and forcing
    userspace to just use different code instead is good, but that's just
    as valid for floating point as it is for MMX, cmpxchg etc.)

    > Only somebody who knows exactly what they were doing is likely to do
    > that - how could it happen by accident? If you really must, put a
    > warning in to say, 'This kernel doesn't support your processor', but
    > doing that just adds more bloat. OK, so the bloat will be freed after
    > boot, but it's still bloat on the boot device, which matters in some
    > embedded systems.

    To be fair, the kernel really ought to just say that and halt. That
    is a fine compromise. It won't make embedded systems folks completely
    happy, because if you've only got 2MB of NVRAM for your whole kernel
    _and_ filesystem including user data (think PDA or cellphone), then a
    hundred bytes here or there is actually worth trimming.

    But then, those sort of embedded folks should just figure out
    compressed software-suspend, and then they can ditch __init data from
    the NVRAM image completely. It's much better to lose all of __init
    than just a few bytes here or there, isn't it?

    -- Jamie
    -
    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: Dave Jones: "Re: [PATCH] Mutilated form of Andi Kleen's AMD prefetch errata patch"

    Relevant Pages