lkml.org 
[lkml]   [2003]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 64GB NUMA-Q after pgcl
    On Sun, Mar 30, 2003 at 08:27:29PM -0800, William Lee Irwin III wrote:
    >> No, that's why it's nontrivial. Otherwise it'd be something like

    On Mon, Mar 31, 2003 at 01:19:45AM +0200, Andrea Arcangeli wrote:
    > I didn't expect that, I'm quite impressed now, I will check your
    > explanation thanks.

    On Mon, Mar 31, 2003 at 08:35:06PM +0200, Andrea Arcangeli wrote:
    > could you try 2.4.21pre5aa2 too if you have some time, I'd love to have
    > a confirm that it boots strightforward on such a machine (sure the
    > normal zone will be pretty small, not enough for AIM7 probably but still
    > ok for doing a large shmfs allocation and have smp_num_cpus tasks
    > attaching in large chunks to work on it) I really expect it to boot, if
    > not it must be a silly bug and I'll fix it, because it should definitely
    > boot on such x86 64G hardware (despite the normal zone will be so
    > small).

    I'll see what those I have to answer to think. I'll have to warn you,
    the NUMA-Q code in 2.4.x hasn't been very heavily focused on recently
    so it may depend on someone testing/debugging the 2.4.x-based tree on
    another machine (we haven't quite lost all the NUMA-Q's in our lab to
    this) before the RAM goes away. I myself don't have guarantees I'll have
    sufficient time for "must do" things -- if I run out of time it's gone
    regardless. Extras are definitely a question of chance.


    On Mon, Mar 31, 2003 at 08:35:06PM +0200, Andrea Arcangeli wrote:
    > About you not caring anymore about the mem_map array size, that still
    > matters on the embedded usage, infact rmap on the embedded usage is the
    > biggest waste there, normally they don't even have swap so if something
    > you should use the rmap provided for truncate, rather than wasting
    > memory in the mem_map array.

    They should be able to utilize the same technique for cutting down
    mem_map, and there are pending bits around that allow the pte_chain
    allocations to be eliminated entirely for file-backed memory, and so
    embedded systems's needs can be accommodated with a bit of extra
    adjustment for !CONFIG_SWAP and they'll never see pte_chains again.


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

    \
     
     \ /
      Last update: 2005-03-22 13:34    [W:0.024 / U:89.340 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site