linux-kernel - Re: [Patch] numa:x86_64: Cacheline aliasing makes for_each_populated

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: <20100821130757.GC3220@sgi.com>
Date:	Sat, 21 Aug 2010 08:07:57 -0500
From:	Robin Holt <holt@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Robin Holt <holt@....com>, Jack Steiner <steiner@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, x86@...nel.org,
	Yinghai Lu <yinghai@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Joerg Roedel <joerg.roedel@....com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Stable Maintainers <stable@...nel.org>
Subject: Re: [Patch] numa:x86_64: Cacheline aliasing makes
 for_each_populated_zone extremely expensive -V2.

> The issue here is that the e820 allocator (which is about to be axed,
> but its successor will need to support similar operations) has a few
> parameters that it takes in: (start, end, size, alignment).  It will
> return a block at address (addr) fulfilling the requirements:
> 
> 	start <= addr
> 	addr+size <= end
> 	(addr % alignment) == 0
> 
> However, for coloring (which is what you're doing here, coloring doesn't
> have to be precise) what you really want is for the last constraint to
> read like:
> 
> 	start <= addr
> 	addr+size <= end
> 	(addr % alignment) == offset
> 
> You can leave your alignment some arbitrarily large value (in the case
> of your 1792-byte structure, you can make the observation that
> 1792*4096 < 8 MiB) and the alignment is simply 1792*(node number).  This
> will over-color massively, of course, *but you're not allocating memory
> you don't need* and so it doesn't really matter.
> 
> However, this does mean that there is a need to be able to pass the
> offset parameter down to the allocator.  Not doing that will either mean
> wasting huge amount of memory or relying on internal behavior of the
> allocator which is already scheduled to change.
> 
> Does this make sense?

It does make sense.

I am not sure how to proceed.  You are saying the e820 allocator is
being replaced.  Yet, this is the allocator used for this section of code.
I feel sort of foolish to tweak the e820 allocator to allow for handling
color only to have it replaced in the near future.

Add to that this simple fix is enough to break up the most egregious
problem which is the scanning of all zones in the system and checking
that zone's pages_present.  If this is adequate, would you accept
this simple patch for now and place expectations on adjusting the e820
replacement allocator later to support color with a simple patch to fix
up the node_data allocations later?

Thanks,
Robin
--
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/