Messages in this thread | | | Date | Sat, 14 Feb 2009 11:10:26 +0900 | From | Tejun Heo <> | Subject | Re: #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
| |