On Wed, 13 Feb 2013 15:03:05 -0600 Robin Holt <holt@xxxxxxx> wrote: > On Wed, Feb 13, 2013 at 12:11:49PM -0800, Andrew Morton wrote: > > On Wed, 13 Feb 2013 09:03:40 -0600 > > Robin Holt <holt@xxxxxxx> wrote: > > > > > > But in a better world, the core kernel would support your machines > > > > adequately and you wouldn't need to maintain that out-of-tree MM code. > > > > What are the prospects of this? > > > > > > We can put it on our todo list. Getting a user of this infrastructure > > > will require changes by Dimitri for the GRU driver (drivers/misc/sgi-gru). > > > He is currently focused on getting the design of some upcoming hardware > > > finalized and design changes tested in our simulation environment so he > > > will be consumed for the next several months. > > > > > > If you would like, I can clean up the driver in my spare time and submit > > > it for review. Would you consider allowing its inclusion without the > > > GRU driver as a user? > > > > >From Cliff's description it sounded like that driver is > > duplicating/augmenting core MM functions. I was more wondering > > whether core MM could be enhanced so that driver becomes obsolete? > > That would be fine with me. The requirements on the driver are fairly > small and well known. We separate virtual addresses above processor > addressable space into two "regions". Memory from 1UL << 53 to 1UL << > 63 is considered one set of virtual addresses. Memory above 1UL << 63 > is considered "shared among a process group". > > I will only mention in passing that we also have a driver which exposes > mega-size pages which the kernel has not been informed of by the EFI > memory map and xvma is used to allow the GRU to fault pages of a supported > page size (eg: 64KB, 256KB 512KB, 2MB, 8MB, ... 1TB). > > The shared address has a couple unusual features. One task makes a ioctl > (happens to come via XPMEM) which creates a shared_xmm. This is roughly > equivalent to an mm for a pthread app. Once it is created, a shared_xmm > id is returned. Other tasks then join that shared xmm. > > At any time, any process can created shared mmap entries (again, currently > via XPMEM). Again, this is like a pthread in that this new mapping is > now referencable from all tasks at the same virtual address. > > There are similar functions for removing the shared mapping. > > The non-shared case is equivalent to a regular mm/vma, but beyond > processor addressable space. > > SGI's MPI utilizes these address spaces for directly mapping portions > of the other tasks address space. This can include processes in other > portions of the machine beyond the processor's ability to physically > address. What exactly is "SGI's MPI" from the kernel POV? A separate out-of-tree driver? If the objective is to "directly map portions of the other tasks address space" then how does this slicing-up of physical address regions come into play? If one wishes to map another mm's memory, wouldn't you just go ahead and map it, regardless of physical address? To what extent is all this specific to SGI hardware characteristics? > The above, of course, is an oversimplification, but should give you and > idea of the big picture design goals. > > Does any of this make sense? Do you see areas where you think we should > extend regular mm functionality to include these functions? > > How would you like me to proceed? I'm obviously on first base here, but overall approach: - Is the top-level feature useful to general Linux users? Perhaps after suitable generalisations (aka dumbing down :)) - Even if the answer to that is "no", should we maintain the feature in-tree rather than out-of-tree? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>