Re: Bug: Discontigmem virt_to_page() [Alpha,ARM,Mips64?]

Andrea Arcangeli (andrea@suse.de)
Fri, 3 May 2002 08:20:57 +0200


On Thu, May 02, 2002 at 12:28:52PM -0700, Gerrit Huizenga wrote:
> 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.

ok.

>
> 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.

sure, the only issue is the API that the hardware provides to advertise
the start/end of the memory for each node. It doesn't matter if it's
squashed or not as long as you still know the start/end of the phys ram
per node. It also won't make any difference with nonlinear or
discontigmem because you need to fill the pgdat anyways to enable the
numa heuristics (node-affine-allocations being the most sensible etc..).

Andrea
-
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/