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

[Eric W. Biederman]

"Yinghai Lu" <yhlu.kernel@xxxxxxxxx> 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.

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

It is good to hear that some users and some systems
get the benefit without trimming.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/