linux-kernel - Re: [PATCH -v2] x86, mm: Probe memory block size for generic x86 64bit

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] [day] [month] [year] [list]

Date:	Tue, 7 Feb 2012 14:35:38 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -v2] x86, mm: Probe memory block size for generic x86 64bit

On Tue, Feb 7, 2012 at 2:11 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 01/30/2012 12:24 AM, Yinghai Lu wrote:
>> Usually if the system support memory remapping to get back memory for mmio
>> range, we will have 128M ... 2G at the end.
>>
>> Try to probe that size.
>>
>> So we can get less entries in /sys/devices/system/memory/
>>
>> -v2: don't probe it every time when /sys/../block_size_byte is showed...
>>
>
> Okay... what on Earth is the point of this?
>
> This just screams "dangerous toxic heuristic that's likely to break
> unusual configurations", and reducing the number of entries in a /sys
> directory is hardly motivation for anything.
>
> You need a much better description of what you're trying to accomplish
> and why that matters in the first place.

that is for memory hotplug support.

on one 2048g system, current x86_64 have 128M as section size, and one
memory_block only include
one section.
So that directory will have 16400 entries.

recent change will try to use block id to find block pointer in /sys
for any section, and reuse that block pointer.
even only one section per block. and that finding will take some time
... already have one patch that will skip the search in that case
during booting up.

but other case, We may still have this finding problem.

So solution could be increase block size just like SGI UV system did.
(harded code to 2g).

This patch is trying to probe the block size to make it match mmio remap size.
for example, AMD system after rev E or Intel Nehalem later system will
have memory range
[0, TOM), [4g, TOM2]. if the memory hole is 2g and total is 128g, TOM
will be 2g, and TOM2 will be 130g.
We could use 2g as block size instead of default 128M.
That will reduce number of entries in  /sys/devices/system/memory/

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