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: <20130823130440.GC10322@mtj.dyndns.org>
Date:	Fri, 23 Aug 2013 09:04:40 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Toshi Kani <toshi.kani@...com>
Cc:	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, hpa@...or.com,
	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.

Hello, Toshi.

On Thu, Aug 22, 2013 at 04:17:41PM -0600, Toshi Kani wrote:
> I am relatively new to Linux, so I am not a good person to elaborate
> this.  From my experience on other OS, huge pages helped for the kernel,
> but did not necessarily help user applications.  It depended on
> applications, which were not niche cases.  But Linux may be different,
> so I asked since you seemed confident.  I'd appreciate if you can point
> us some data that endorses your statement.

We are talking about the kernel linear mapping which is created during
early boot, so if it's available and useable there's no reason not to
use it.  Exceptions would be earlier processors which didn't do 1G
mappings or e820 maps with a lot of holes.  For CPUs used in NUMA
configurations, the former has been history for a bit now.  Can't be
sure about the latter but it'd be surprising for that to affect large
amount of memory in the systems that are of interest here.  Ooh, that
reminds me that we probably wanna go back to 1G + MTRR mapping under
4G.  We're currently creating a lot of mapping holes.

> My worry is that the code is unlikely tested with the special logic when
> someone makes code changes to the page tables.  Such code can easily be
> broken in future.

Well, I wouldn't consider flipping the direction of allocation to be
particularly difficult to get right especially when compared to
bringing in ACPI tables into the mix.

> To answer your other question/email, I believe Tang's next step is to
> support local page tables.  This is why we think pursing SRAT earlier is
> the right direction.

Given 1G mappings, is that even a worthwhile effort?  I'm getting even
more more skeptical.

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/