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

[Andrea Arcangeli]

On Thu, May 02, 2002 at 09:22:07PM +0200, Daniel Phillips wrote:
> On Thursday 02 May 2002 20:41, Andrea Arcangeli wrote:
> > On Thu, May 02, 2002 at 10:16:55AM -0700, William Lee Irwin III wrote:
> > > On Thu, May 02, 2002 at 09:10:00AM -0700, Martin J. Bligh wrote:
> > > >> Even with 64 bit DMA, the real problem is breaking the assumption
> > > >> that mem between 0 and 896Mb phys maps 1-1 onto kernel space.
> > > >> That's 90% of the difficulty of what Dan's doing anyway, as I
> > > >> see it.
> > > 
> > > On Thu, May 02, 2002 at 06:40:37PM +0200, Andrea Arcangeli wrote:
> > > > control on virt_to_page, pci_map_single, __va.  Actually it may be as
> > > > well cleaner to just let the arch define page_address() when
> > > > discontigmem is enabled (instead of hacking on top of __va), that's a
> > > > few liner. (the only true limit you have is on the phys ram above 4G,
> > > > that cannot definitely go into zone-normal regardless if it belongs to a
> > > > direct mapping or not because of pci32 API)
> > > > Andrea
> > > 
> > > Being unable to have any ZONE_NORMAL above 4GB allows no change at all.
> > 
> > No change if your first node maps the whole first 4G of physical address
> > space, but in such case nonlinear cannot help you in any way anyways.
> 
> You *still don't have a clue what config_nonlinear does*.
> 
> It doesn't matter if the first 4G of physical memory belongs to node zero.
> Config_nonlinear allows you to map only part of that to the kernel virtual
> space, and the rest would be mapped to highmem.  The next node will map part
> of its local memory (perhaps the next 4 gig of physical memory) to a different
> part of the kernel virtual space, and so on, so that in the end, all nodes
> have at least *some* zone_normal memory.

You are the one that has no clue of what I'm talking about. Go ahead, do
that and you'll see the corruption you get after the first vmalloc32 or
similar.

This has nothing to do with nonlinaer or anything discontigmem/numa.
This is all about the GFP kernel API with pci32.

> 
> Do you now see why config_nonlinear is needed in this case?  Are you
> willing to recognize the possibility that you might have missed some other
> cases where config_nonlinear is needed, and config_discontigmem won't do
> the job?
> 
> -- 
> Daniel

Andrea