|
xen-devel
[Xen-devel] Re: [GIT PULL] xen /proc/mtrr implementation
Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> writes:
> On Fri, 15 May 2009 16:49:12 -0700
> Jeremy Fitzhardinge <jeremy@xxxxxxxx> 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.
I don't know that it makes sense to remove mtrrs but it certainly
doesn't make sense to use them if you can avoid it.
>> >> 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.
Wow. We had a lot of those slip in. Definitely time to fix the
drivers.
>> > 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?
PPro is roughly when PAT came out. I remember discussing this a while
ago and the conclusion was that there are very few systems with MTRRs
that don't have a usable PAT implementation. I expect many of those
systems are on their last legs today.
>> 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.
There are only 3 states that are interesting. WB UC and WC. Since
Xen controls the page tables anyway. I expect it can even remap
it feels like it.
>> 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.
I won't argue that having MTRRs when you can makes sense. It is a bit
weird in a vitalized system. At a practical level there are an
increasing number of systems for which MTRRs are unusable because the
BIOS sets up overlapping mtrrs. With cheap entry level systems
shipping with 4G I expect it is becoming a majority of systems.
Eric
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home