linux-kernel - Re: [PATCH 0/8] x86, acpi: Move acpi_initrd

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: <20130823145732.GC3277@htj.dyndns.org>
Date:	Fri, 23 Aug 2013 10:57:32 -0400
From:	Tejun Heo <tj@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Toshi Kani <toshi.kani@...com>,
	Zhang Yanfei <zhangyanfei.yes@...il.com>,
	Tang Chen <tangchen@...fujitsu.com>, konrad.wilk@...cle.com,
	robert.moore@...el.com, lv.zheng@...el.com, rjw@...k.pl,
	lenb@...nel.org, tglx@...utronix.de, mingo@...e.hu,
	akpm@...ux-foundation.org, trenn@...e.de, yinghai@...nel.org,
	jiang.liu@...wei.com, wency@...fujitsu.com, laijs@...fujitsu.com,
	isimatu.yasuaki@...fujitsu.com, izumi.taku@...fujitsu.com,
	mgorman@...e.de, minchan@...nel.org, mina86@...a86.com,
	gong.chen@...ux.intel.com, vasilis.liaskovitis@...fitbricks.com,
	lwoodman@...hat.com, riel@...hat.com, jweiner@...hat.com,
	prarit@...hat.com, zhangyanfei@...fujitsu.com,
	yanghy@...fujitsu.com, x86@...nel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier.

On Fri, Aug 23, 2013 at 10:35:07AM -0400, Tejun Heo wrote:
> Yeah, it's true that MTRRs are nasty.  On the other hand, we've been
> doing that for over a decade and are still doing it anyway if I'm not
> mistaken.  It probably isn't a big difference but it's still a bit sad
> that this is likely causing small performance regression out in the
> wild.

Just went over the processor manual and it doesn't seem like doing the
above would be a good idea.

  System Programming Guide, Part 1

  11.11.9 Large Page Size Considerations

 ... 
 Because the memory type for a large page is cached in the TLB, the
 processor can behave in an undefined manner if a large page is mapped
 to a region of memory that MTRRs have mapped with multiple memory
 types.
 ...
 If a large page maps to a region of memory containing different
 MTRR-defined memory types, the PCD and PWT flags in the page-table
 entry should be set for the most conservative memory type for that
 range. For example, a large page used for memory mapped I/O and
 regular memory 11-48 Vol. 3A MEMORY CACHE CONTROL
 ...

 The Pentium 4, Intel Xeon, and P6 family processors provide special
 support for the physical memory range from 0 to 4 MBytes,
 ...
 Here, the processor maps the memory range as multiple 4-KByte pages
 within the TLB. This operation insures correct behavior at the cost
 of performance. To avoid this performance penalty, operating-system
 software should reserve the large page option for regions of memory
 at addresses greater than or equal to 4 MBytes.

So, yeah, the current behavior seems like the right thing to do.

Thanks.

-- 
tejun
--
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/