lkml.org 
[lkml]   [2002]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Bug: Discontigmem virt_to_page() [Alpha,ARM,Mips64?]
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:25    [W:0.121 / U:3.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site