[lkml]   [2008]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] x86_32: trim memory by updating e820 v3
    On Tue, Apr 29, 2008 at 12:19 PM, Eric W. Biederman
    <> wrote:
    > "Yinghai Lu" <> writes:
    > >> 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.
    > True but at least that one is visible.
    > > 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.
    > Right. Ram trimming (changing memory from WB to UC) is the potential
    > problem.
    > See my other post, in short I think we can address safely address all
    > of the systems where the only problem is the selection of MTRRs by the
    > BIOS.

    BIOS should provide the selection...

    > Then have an option (mtrr_chunk_size) for RAM trimming that is
    > off by default.

    Yes. there is CONFIG option and boot command line to enable it.


     \ /
      Last update: 2008-04-29 21:47    [W:0.022 / U:5.308 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site