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    [W:2.925 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site