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: <200711200416.32954.ak@suse.de>
Date:	Tue, 20 Nov 2007 04:16:32 +0100
From:	Andi Kleen <ak@...e.de>
To:	clameter@....com
Cc:	akpm@...ux-foundation.org, travis@....com,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	linux-kernel@...r.kernel.org
Subject: Re: [rfc 08/45] cpu alloc: x86 support


> 4k cpu configurations with 1k nodes:
>
> 	4096 * 16MB = 64TB of virtual space.
>
> Maximum theoretical configuration 16384 processors 1k nodes:
>
> 	16384 * 16MB = 256TB of virtual space.
>
> Both fit within the established limits established.

I might be pointing out the obvious, but on x86-64 there is definitely not 
256TB of VM available for this.

Not even 64TB, as long as you want to have any
other mappings in kernel (total kernel memory 128TB, but it is split in
half for the direct mapping) 

BTW if you allocate any VM you should also update
Documentation/x86_64/mm.txt which describes the mapping

> Index: linux-2.6/include/asm-x86/pgtable_64.h
> ===================================================================
> --- linux-2.6.orig/include/asm-x86/pgtable_64.h	2007-11-19
> 15:45:07.638390147 -0800 +++
> linux-2.6/include/asm-x86/pgtable_64.h	2007-11-19 15:55:53.165640248 -0800
> @@ -138,6 +138,7 @@ static inline pte_t ptep_get_and_clear_f
>  #define VMALLOC_START    _AC(0xffffc20000000000, UL)
>  #define VMALLOC_END      _AC(0xffffe1ffffffffff, UL)
>  #define VMEMMAP_START	 _AC(0xffffe20000000000, UL)
> +#define CPU_AREA_BASE	 _AC(0xffffffff84000000, UL)

That's slightly less than 1GB before you bump into the maximum.
But you'll bump into the module mapping even before that.

For 16MB/CPU and the full 1GB that's ~123 CPUs if my calculations are correct. 
Even for a  not Altix that's quite tight.

I suppose 16MB/CPU are too large.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ