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]

Date:	Sat, 24 Aug 2013 00:54:19 +0800
From:	Zhang Yanfei <zhangyanfei.yes@...il.com>
To:	Toshi Kani <toshi.kani@...com>, Tejun Heo <tj@...nel.org>
CC:	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

On 08/24/2013 12:14 AM, Toshi Kani wrote:
> Hello,
> 
> On Fri, 2013-08-23 at 09:04 -0400, Tejun Heo wrote:
>> 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.
> 
> Thanks for the explanation.
> 
>>> 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.
> 
> With 1G mappings, I agree that it won't make much difference.
> 
> I still think acpi table info should be available earlier, but I do not
> think I can convince you on this.  This can be religious debate.
> 
> Tang, what do you think?  Are you OK to try Tejun's suggestion as well? 
> 

By saying TJ's suggestion, you mean, we will let memblock to control the
behaviour, that said, we will do early allocations near the kernel image
range before we get the SRAT info?

If so, yeah, we have been working on this direction. By doing this, we may
have two main changes:

1. change some of memblock's APIs to make it have the ability to allocate
   memory from low address.
2. setup kernel page table down-top. Concretely, we first map the memory
   just after the kernel image to the top, then, we map 0 - kernel image end.

Do you guys think this is reasonable and acceptable?

-- 
Thanks.
Zhang Yanfei
--
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/