lkml.org 
[lkml]   [2009]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] x86/pci: make pci_mem_start to be aligned only -v4

    * Linus Torvalds <torvalds@linux-foundation.org> wrote:

    > On Fri, 17 Apr 2009, Ingo Molnar wrote:
    > >
    > > Could we perhaps round up to 1MB in this case too?
    >
    > (The below 1MB one).
    >
    > I'd argue against it, at least in this incarnation. I can well
    > imagine somebody wanting to do resource management in the 640k-1M
    > window, so..

    ok - indeed - if there's some super-small system with limited
    address lines and all physical addresses tightly packed with RAM?

    > > Would it make sense to round up everything that is listed in the
    > > E820 map? Just in case the BIOS is not entirely honest about the
    > > true extent of that area.
    >
    > Well, it would probably work, but on the other hand, when we see
    > "E820_RAM", that means that we really _can_ trust that that E820
    > entry is right, since we're going to use it as RAM (and Windows
    > would too), and if it wasn't RAM, really bad things would happen.
    >
    > So E820_RAM is a _lot_ more trustworthy than the other cases. If
    > we're rounding up by reasonably large amounts like 32MB or even
    > more, I really think we should do so for the things we really know
    > are there, and that we really fundamentally know come in big
    > granularities.
    >
    > The other entries in the e820 map can reasonably be 4kB or
    > something, because they are an IO-APIC or whatever. I can't say
    > that I'd feel happy putting a guard area around something like
    > that. But RAM? Sure, it can come in 384kB chunks (think RAM
    > remapping for the low 1MB area), but it doesn't tend to happen
    > when we're talking gigs any more.

    One of my systems is a bit weird, with such a checkered RAM map:

    BIOS-provided physical RAM map:
    BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) 0.639 MB RAM
    BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) 0.001 MB
    [ hole ] 0.250 MB
    BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) 0.125 MB
    BIOS-e820: 0000000000100000 - 000000003ed94000 (usable) 1004.5 MB RAM
    BIOS-e820: 000000003ed94000 - 000000003ee4e000 (ACPI NVS) 0.7 MB
    BIOS-e820: 000000003ee4e000 - 000000003fea2000 (usable) 16.3 MB RAM
    BIOS-e820: 000000003fea2000 - 000000003fee9000 (ACPI NVS) 0.3 MB
    BIOS-e820: 000000003fee9000 - 000000003feed000 (usable) 0.15 MB RAM
    BIOS-e820: 000000003feed000 - 000000003feff000 (ACPI data 0.07 MB
    BIOS-e820: 000000003feff000 - 000000003ff00000 (usable) 0.004 MB RAM
    [ hole ] 1.0 MB
    [ hole ] 3072.0 MB

    On this map, using your scheme, we'd fill up that small 1MB hole up
    to 1GB [mockup]:

    BIOS-e820: 000000003ff00000 - 0000000040000000 (RAM buffer)

    I guess that's a good thing not just for robustness: a chipset might
    be faster when DMA or mmio is on some well-isolated physical memory
    range, not too close to real RAM or other devices?

    Bits of the low hole:

    00000000-0009fbff : System RAM
    0009fc00-0009ffff : reserved
    000c0000-000dffff : pnp 00:01
    000e0000-000fffff : reserved
    00100000-3ed93fff : System RAM

    would still be available to dynamic PCI resources - as the 64K
    rounding would leave it alone.

    Ingo


    \
     
     \ /
      Last update: 2009-04-17 15:21    [W:0.056 / U:90.564 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site