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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m18wyw31v4.fsf@frodo.ebiederm.org>
Date:	Tue, 29 Apr 2008 12:19:43 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	"Yinghai Lu" <yhlu.kernel@...il.com>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"Gabriel C" <nix.or.die@...glemail.com>,
	"Andi Kleen" <andi@...stfloor.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Jesse Barnes" <jesse.barnes@...el.com>,
	"Mika Fischer" <mika.fischer@...pnet.de>, balajirrao@...il.com
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v3

"Yinghai Lu" <yhlu.kernel@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/