lkml.org 
[lkml]   [2009]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL] xen /proc/mtrr implementation
    On Fri, 15 May 2009 16:49:12 -0700
    Jeremy Fitzhardinge <jeremy@goop.org> wrote:

    > Eric W. Biederman wrote:
    > >> /proc/mtrr is in wide use today. It may be planned for
    > >> obsolescence, but there's no way you can claim its obsolete today
    > >> (my completely up-to-date F10 X server is using it, for example).
    > >> We don't break oldish usermode ABIs in new kernels.
    > >>
    > >
    > > Sure it is. There is a better newer replacement. It is taking a
    > > while to get userspace transitioned but that is different.
    > > Honestly I am puzzled why that it but whatever.
    > >
    >
    > There's no mention in feature-removal-schedule.txt.
    >
    > >> Besides, the MTRR code is also a kernel-internal API, used by DRM
    > >> and other drivers to configure the system MTRR state. Those
    > >> drivers will either perform badly or outright fail if they can't
    > >> set the appropriate cachability properties. That is not obsolete
    > >> in any way.
    > >
    > > There are about 5 of them so let's fix them.
    > >
    >
    > Well, I count at least 30+, but anyway.
    >
    > > With PAT we are in a much better position both for portability and
    > > for flexibility.
    > >
    >
    > PAT is relatively recent, and even more recently bug-free. There are
    > many people with processors which can't or won't do PAT; what's the
    > plan to support them? Just hit them with a performance regression?
    > Or wrap MTRR in some other API?
    >
    > > Is it possible to fix PAT and get that working first. That is
    > > very definitely the preferend API.
    > >
    >
    > Sure, when available. We're sorting out the details for Xen, but
    > even then it may not be available, either because we're running on an
    > old version of Xen, or because some other guest is using PAT
    > differently.
    >
    > But I honestly don't understand the hostility towards 120 lines of
    > code to make an interface (albeit legacy/deprecated/whatever) behave
    > in an expected way.

    FWIW I think supporting the MTRR API in Xen makes sense. There's a lot
    of old code out there that wants it; would be nice if it mostly worked,
    especially at such a minimal cost. It's taken awhile to get PAT going
    (and there are still issues here and there) so having the MTRR stuffa
    available is awfully nice.

    --
    Jesse Barnes, Intel Open Source Technology Center


    \
     
     \ /
      Last update: 2009-05-16 05:25    [W:0.024 / U:0.120 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site