Messages in this thread | | | Date | Tue, 29 Apr 2008 13:04:36 -0700 | From | "Yinghai Lu" <> | Subject | Re: [PATCH] x86: mtrr cleanup for converting continuous to discrete layout v5 |
| |
On Tue, Apr 29, 2008 at 12:00 PM, Eric W. Biederman <ebiederm@xmission.com> wrote: > Yinghai Lu <yhlu.kernel.send@gmail.com> writes: > > > some BIOS like to use continus MTRR layout, and may X driver can not add > > WB entries for graphical cards when 4g or more RAM installed. > > > > the patch will change MTRR to discrete. > > > > mtrr_chunk_size= could be used to have smaller continuous block to hold holes. > > default is 256m, could be set according to size of graphics card memory. > > > > v2: fix -1 for UC checking > > v3: default to disable, and need use enable_mtrr_cleanup to enable this feature > > skip the var state change warning. > > remove next_basek in range_to_mtrr() > > v4: correct warning mask. > > v5: CONFIG_MTRR_SANITIZER > > > > Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> > > Skimming through the code it looks fairly sane. > > I do think it would be good to split this patch into two pieces. > 1) The mtrr rewriter/sanitizer/normalize. > All it does it should do is rewrite the MTRRs with a > semantically equivalent value. This code should always be > safe and work on any system with MTRRs. > > This works around otherwise sane bios's that simply prefer > to have contiguous MTRRs. > > I don't see a reason why this code should be configurable. > > This approach avoids earlier concerns because it starts > with the existing MTRR layout and not with the e820 map. > > 2) The mtrr_chunk_size code that rounds things off and allows > us to use discrete MTRRs by reducing some RAM to uncacheable. > Because it makes things uncacheable it has potentially bad > side effects on performance and thus potentially bad side > effects on functionality. For areas like the SMM and ACPI > especially as they usually occur at the end of RAM just > below 4G. > > The chunk size code should be configurable and default to off > because it has potential side effects. A KConfig option may > also be appropriate. It asks an interesting trade off question > do you want your BIOS to be fast or X.
(less memory + fast X) or (more 8M RAM + slow...)
YH
| |