lkml.org 
[lkml]   [2009]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: #tj-percpu has been rebased
Hello,

H. Peter Anvin wrote:
> Okay, let's think about this a bit.
>
> At least for x86, there are two cases:
>
> - 32 bits. The vmalloc area is *extremely* constrained, and has the
> same class of fragmentation issues as main memory. In fact, it might
> have *more* just by virtue of being larger.

We can go for smaller chunks but I don't really see any perfect
solution here. If a machine is doing 16 way SMP on 32bit, it's not
gonna scale very well anyway.

> - 64 bits. At this point, we have with current memory sizes(*) an
> astronomically large virtual space. Here we have no real problem
> allocating linearly in virtual space, either by giving each CPU some
> very large hunk of virtual address space (which means each percpu area
> is contiguous in virtual space) or by doing large contiguous allocations
> out of another range.
>
> It doesn't seem to make sense to me at first glance to be any advantage
> to interlacing the CPUs. Quite on the contrary, it seems to utterly
> preclude ever doing PMDs with a win, since (a) you'd be allocating real
> memory for CPUs which aren't actually there and (b) you'd have the wrong
> NUMA associativity.

For (a), we can do hotplug online/offline thing for dynamic areas if
necessary. (b) why would it have the wrong NUMA associativity?

Thanks.

--
tejun


\
 
 \ /
  Last update: 2009-02-14 03:15    [from the cache]
©2003-2011 Jasper Spaans