Messages in this thread | | | From | Gerrit Huizenga <> | Subject | Re: Bug: Discontigmem virt_to_page() [Alpha,ARM,Mips64?] | Date | Thu, 02 May 2002 12:28:52 -0700 |
| |
In message <20020502201043.L11414@dualathlon.random>, > : Andrea Arcangeli writ es: > On Thu, May 02, 2002 at 09:58:02AM -0700, Gerrit Huizenga wrote: > > In message <3971861785.1020330424@[10.10.2.3]>, > : "Martin J. Bligh" writes: > > > > With numa-q there's a 512M hole in each node IIRC. that's fine > > > > configuration, similar to the wildfire btw. > > > > > > There's 2 different memory models - the NT mode we use currently > > > is contiguous, the PTX mode is discontiguous. I don't think it's > > > as simple as a 512Mb fixed size hole, though I'd have to look it > > > up to be sure. > > > > No - it definitely isn't as simple as a 512 MB hole. Depends on how much > > I meant that as an example, I recall that was valid config, 512M of ram > and 512M hole, then next node 512M ram and 512M hole etc... Of course it > must be possible to vary the mem size if you want more or less ram in > each node but still it doesn't generate a problematic layout for > discontigmem (i.e. not 256 discontigous chunks or something of that > order).
I *think* the ranges were typically aligned to 4 GB, although with 8 GB in a single node, I don't remember what the mapping layout looked like.
Which made everything but node 0 into HIGHMEM.
With the "flat" addressing mode that Martin has been using (the dummied down for NT version) everything is squished together. That makes it a bit harder to do node local data structures, although he may have enough data from the MPS table to split memory appropriately.
gerrit - 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/
| |