[lkml]   [2002]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Bug: Discontigmem virt_to_page() [Alpha,ARM,Mips64?]
    Daniel Phillips wrote:
    > The boot loader must have provided at least some contiguous physical
    > memory in order to load the kernel, the compressed disk image and give
    > us a little working memory. (For practical purposes, we're most likely to
    > have been provided with a full gig, or whatever is appropriate according
    > to the mem= command line setting, but lets pretend it's a lot less than
    > that.) Now, the first thing we need to do is fill in enough of the
    > Naturally, during initialization of the hash table, we want to be sure
    > not to perform and phys_to_logical translations, as would be required to
    > read values from the page tables during swap-out for example. Probably
    > there's already no possibility of that, but it needs a comment at least.
    > I can't provide any more details than that, because I'm not familiar
    > with the way the iseries boots. Anton is the man there.

    The way it works on iSeries is the HV provides a 64MB physicaly
    contiguous load area. The kernel & working storage, including the
    logical->physical (or absolute in our terms) must fit in this space.
    Even with a 256KB chunk size and a simple array for translation, the
    memory consumption is not excessive. Each array entry is 32bits,
    allowing a 32+12(page offset) = 44b of physical addessability and a 1MB
    array allows 32GB of translations.

    We don't need the reverse translation on iSeries as the kernel never
    knows about the actual hardware address, other than when putting an
    entry in the hardware page tables (processor and I/O). One other thing
    to not is that Linux _always_ runs with relocation enabled on iSeries so
    there is never a point, other than way I mention above, when the
    hardware address matters.

    > We ought to have some clue about the maximum number of physical memory
    > chunks available to us. I doubt *every* partition is going to be
    > provided 256 GB of memory. In fact, the real amount we need will be
    > considerably less, and the phys_to_logical table will be smaller than
    > 16 MB, say, 1 MB. Just allocate the whole thing and be done with it.


    > > How do you know what
    > > the size of the table should be if the number of chunks varies
    > > dramatically?
    > The most obvious and practical approach is to have the boot loader tell
    > us, we allocate the maximum size needed, and won't worry about that
    > again.

    Yes, we do know the maximum memory possible, both system wide, and more
    importantly within a partition. In fact the way it works today, a
    partition is defined to the hypervisor with a current memory size to use
    and a max memory size. The max is required because the hardware page
    table for PowerPC is allocated to the max size before the partition
    boots. Becuase the page table must be physically contiguous, it is
    allocated for the partition when the system boots. The size of the
    Linux translation tables is a similar issue where the worst case should
    just be considered and allocated at Linux boot time.

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

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