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.100 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site