[lkml]   [2000]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: how does kernel get the "current" task struct?
    Stephen C. Tweedie wrote:
    > > I don't see why it's necessary though. The allocator should simply use
    > > absolute address values for pairing instead of zone-relative
    > > addresses.. is there anything more to it than that?
    > Yes --- you need 8k allocations to be 8k-aligned physically, and 64k
    > allocations to be 64k-aligned, etc. Just to think of one example, Intel
    > MTRR absolutely requires that the address of a memory range is a
    > multiple of the size of the range, and you need aligned zones to create
    > such regions.

    That's what I said. E.g., you have a zone starting at 4k that's 32k
    long. You initialise the allocator by calling free_page on each page.
    The buddy structure ends up looking like this:

    4k @ 4k
    16k @ 8k
    4k @ 24k

    In other words, you get aligned allocations without having to align the
    zones. As far as I can see, it's a simple matter of making the "get
    my opposite buddy page" logic use absolute address values instead of
    zone-relative ones.

    > This needn't be a problem --- you can easily create a zone aligned at a
    > large (eg. 16MB) granularity, without filling it with free pages. As an
    > example, the low-memory zone doesn't populate the free page list with
    > pages in the 640k-1M hole. Just because your physical page region isn't
    > aligned nicely doesn't mean you cannot align the zone itself.

    I guess that's what I said too, but I don't see why aligning the zone is
    needed. May as well leave zones representing actual memory ranges,
    rather than some artificially aligned ranges for no obvious reason.
    Less work for people writing ports, less to go invisibly wrong...

    -- Jamie

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

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