Re: ZONE_PADDING wastes 4 bytes of the new cacheline

From: Andrea Arcangeli (andrea_at_novell.com)
Date: 10/23/04

  • Next message: C.Y.M: "Re: Unknown symbol kill_proc_info in 2.6.10-rc1" 
    Date:	Sat, 23 Oct 2004 11:59:55 +0200
To: Nick Piggin <nickpiggin@yahoo.com.au>

    On Sat, Oct 23, 2004 at 02:33:39PM +1000, Nick Piggin wrote:
    > Andrea Arcangeli wrote:
    > >I don't see any benefit in limiting the high order, infact it seems a
    > >bad bug. If something you should limit the _small_ order, so that the
    > >high order will have a slight chance to succeed. You're basically doing
    > >the opposite.
    > >
    >
    > You need the order there so someone can't allocate a huge amount
    > of memory and deplete all your reserves and crash the system.

    what? the point of alloc_pages is to allow people to allocate memory,
    what's the difference of 1 2M allocation and 512 4k allocations? No
    difference at all. Infact if something the 512 4k allocations hurts a
    lot more since they can fragment the memory, while the single 2M
    allocation will not fragment the memory. So if you really want to limit
    something you should do the exact opposite of what the allocator is
    doing.

    > For day to day running, it should barely make a difference because
    > the watermarks will be an order of magnitude larger.

    yes, it makes little difference, this is why it doesn't hurt that much.

    > AFAIKS, pages_min, pages_low and pages_high are all required for
    > what we want to be doing. I don't see you you could remove any one
    > of them and still have everything functioning properly....
    >
    > I haven't really looked at 2.4 or your patches though. Maybe I
    > misunderstood you.

    2.4 has everything functionally properly but it has no
    pages_min/low/high, it only has the watermarks. Infact the watermarks
    _are_ low/min/high. That's what I'm forward porting to 2.6 (besides
    fixing minor mostly not noticeable but harmful bits like the order
    nosense described above).
    -
    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/

  • Next message: C.Y.M: "Re: Unknown symbol kill_proc_info in 2.6.10-rc1"

    Relevant Pages

    • Tru64 issues with Infinite limits
      ... An automated test in my nightly build was failing due to Out of Memory ... Cannot allocate block 146 ...
      (comp.unix.tru64)
    • Re: run-time vs compile-time
      ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
      (alt.comp.lang.learn.c-cpp)
    • Re: run-time vs compile-time
      ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
      (comp.lang.cpp)
    • Re: SBCL performance on OS X
      ... > than C at allocating memory. ... > OpenMCL on the powerbook is an order of magnitude slower than SBCL ... comparison with the lisp implementation of your experiment terribly ... allocate an extra two-word structure to store it in, ...
      (comp.lang.lisp)
    • Re: Sharing memory between kernelspace and userspace
      ... deallocate, on a totally dynamic basis, userspace ... Let userspace allocate shared memory visible to multiple ... and pass that into the kernel for it to write to. ...
      (Linux-Kernel)