| Date | Mon, 19 Nov 2007 17:35:06 -0800 | From | "H. Peter Anvin" <> | Subject | Re: [rfc 08/45] cpu alloc: x86 support |
| |
Christoph Lameter wrote: > > For the UP and SMP case map the area using 4k ptes. Typical use of per cpu > data is around 16k for UP and SMP configurations. It goes up to 45k when the > per cpu area is managed by cpu_alloc (see special x86_64 patchset). > Allocating in 2M segments would be overkill. > > For NUMA map the area using 2M PMDs. A large NUMA system may use > lots of cpu data for the page allocator data alone. We typically > have large amounts of memory around on those size. Using a 2M page size > reduces TLB pressure for that case. > > Some numbers for envisioned maximum configurations of NUMA systems: > > 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. >
You're making the assumption here that NUMA = large number of CPUs. This assumption is flat-out wrong.
On x86-64, most two-socket systems are still NUMA, and I would expect that most distro kernels probably compile in NUMA. However, burning megabytes of memory on a two-socket dual-core system when we're talking about tens of kilobytes used would be more than a wee bit insane.
I do like the concept, overall, but the above distinction needs to be fixed.
-hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|