Re: [PATCH] x86_32: trim memory by updating e820 v3

["Yinghai Lu" <yhlu.kernel@gmail.com>]

On Tue, Apr 29, 2008 at 10:29 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
> Ingo Molnar <mingo@elte.hu> writes:
>
>  > * Eric W. Biederman <ebiederm@xmission.com> wrote:
>  >
>  >> So lets concentrate on PAT to solve contiguous MTRR region problems.
>  >>
>  >> We can upgrade UC to WC with pat.  As well as demote WB to UC or WC.
>  >> So for those regions we know about we should be in good shape.
>  >
>  > sure, but whatever we do now in the sysfs API space, it will hit distros
>  > only in a year, relistically, because Xorg also has to adopt to it. The
>  > workaround from Yinghai looks reasonably configurable - if we mess up
>  > (say an SMM comes in while we fiddle with the MTRRs) we'll likely get a
>  > lockup right then, during bootup, so it wont be hard to realize what
>  > went wrong. In that sense it's in fact safer to do it during early init
>  > than let the user do it via some script, because the window is smaller,
>  > etc.
>  >
>  > we still default to the safe mode of course and dont touch MTRRs, but
>  > for note the various configuration options that are available to distros
>  > and users.
>
>  The potential problem isn't while we reprogram the MTRRs, the potential
>  problem is mapping the SMM area uncachable.  In which case we will
>  make each SMM interrupt drastically slower.  Which can have all kinds of
>  unpleasant side effects.

and ACPI area too.

that only try to make the continuous to discrete layout. and still try
to cover all that is (WBs - UC) directly with WB.
only thing is that could run out of MTRR..., and mtrr_gran_size is
used to avoid that.
then some RAM that is less than mtrr_gran_size could be dumped.
so mtrr_gran_size could do sth.
anyway this patch only can meet one end.
for example Mika Fischer's system doesn't need to trim any RAM in MTRR.
but for Gabriel's system may need to trim some RAM in MTRR.

current mtrr_gran_size is default to 64M...

may need another patch to loop all mtrr_chunk_size (2g, 1g, ...64M) ,
mtrr_gran_size (2g, 1g, ...1M) meet
1. leave one or two entry for X server driver
2. lose less cover for RAM in MTRR.

anyway that should be done in BIOS. but ...

>
>  If we really can mess up SMM mode that way we have a really nasty
>  interaction that is horrible to debug, or recognize.
>
>  Further the opportunity for this kind of fixup is small.
>  Newer AMD systems don't need it as they have an extra
>  way of specifying memory about 4G as WB.  Systems with just
>  the MTRRs can only use this when they have right around 4GB
>  because with more memory there are not enough MTRRs to leave them
>  non-overlapping and still mark all of memory WB.

yes. the patch handle the AMD rev f later with mtrr_tom2.
I have one system that give me - ( strange one ?)
0 - 128g WB
4g-512m, 4g wc

after the patch i got

0 - 2048m wb
2048m - 1024m wb
3072m - 3584m wb

YH