mm: export mmu notifier invalidates

Commenting on this patch ended with Andrea's post on 07Jan, which was a more-or-less endorsement and a question about support for extended vma abstractions in kernel modules out of tree.
(that comment can be found at http://marc.info/?l=linux-mm&m=135757292605395&w=2)

I'd like to make the request again to consider export of these two symbols.

We at SGI have a need to address some very high physical address ranges with our GRU (global reference unit), sometimes across partitioned machine boundaries and sometimes with larger addresses than the cpu supports.
We do this with the aid of our own 'extended vma' module which mimics the vma. When something (either unmap or exit) frees an 'extended vma' we use the mmu notifiers to clean them up.

We had been able to mimic the functions __mmu_notifier_invalidate_range_start() and __mmu_notifier_invalidate_range_end() by locking the per-mm lock and walking the per-mm notifier list. But with the change to a global srcu lock (static in mmu_notifier.c) we can no longer do that. Our module has no access to that lock.

So we request that these two functions be exported.

...

Quoted 26 lines · On Tue, 12 Feb 2013 15:35:34 -0600 Cliff Wickman <[email protected]> wrote:

Commenting on this patch ended with Andrea's post on 07Jan, which was a more-or-less endorsement and a question about support for extended vma abstractions in kernel modules out of tree.
(that comment can be found at http://marc.info/?l=linux-mm&m=135757292605395&w=2)

I'd like to make the request again to consider export of these two symbols.

We at SGI have a need to address some very high physical address ranges with our GRU (global reference unit), sometimes across partitioned machine boundaries and sometimes with larger addresses than the cpu supports.
We do this with the aid of our own 'extended vma' module which mimics the vma. When something (either unmap or exit) frees an 'extended vma' we use the mmu notifiers to clean them up.

We had been able to mimic the functions __mmu_notifier_invalidate_range_start() and __mmu_notifier_invalidate_range_end() by locking the per-mm lock and walking the per-mm notifier list. But with the change to a global srcu lock (static in mmu_notifier.c) we can no longer do that. Our module has no access to that lock.

So we request that these two functions be exported.

...

Review

Quoted 2 lines

(quoted diff) +2 -0

+EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_start);
+EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_end);

erk. Having remote, modular, out-of-tree *sending* mmu notifications is pretty abusive :(

I don't have a problem with the patch personally. It's a GPL export and it's only 2 lines and if we break it, you own both pieces ;)

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?

Quoted 3 lines

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

In the transition period, could we allow this change in and then remove the exports as part of that driver being accepted? That would help us with an upcoming distro release.

Quoted 10 lines · On Wed, 13 Feb 2013 09:03:40 -0600 Robin Holt <[email protected]> wrote:

Quoted 3 lines

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.

Quoted 5 lines

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?

Quoted 13 lines · Andrew Morton

Quoted 10 lines · On Wed, 13 Feb 2013 09:03:40 -0600 Robin Holt <[email protected]> wrote:

Quoted 3 lines

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.

Quoted 7 lines

Quoted 5 lines

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.

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?

Quoted 47 lines · On Wed, 13 Feb 2013 15:03:05 -0600 Robin Holt <[email protected]> wrote:

Quoted 13 lines · Andrew Morton

Quoted 10 lines · On Wed, 13 Feb 2013 09:03:40 -0600 Robin Holt <[email protected]> wrote:

Quoted 3 lines

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.

Quoted 7 lines

Quoted 5 lines

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.

Quoted 4 lines

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?

Quoted 6 lines

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?

Quoted 1 line

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?

I am open to suggestions. Can you suggest existing kernel functionality that allows one task to map another virtual address space into their va space to allow userland-to-userland copies without system calls? If there is functionality that has been introduced in the last couple years, I could very well have missed it as I have been fairly heads-down on other things for some time.

Quoted 1 line

To what extent is all this specific to SGI hardware characteristics?

SGI's hardware allows two things, a vastly larger virtual address space and the ability to access memory in other system images on the same numa fabric which are beyond the processsors physical addressing capabilities.

I am fairly sure Cray has taken an older version of XPMEM and stripped out a bunch of SGI specific bits and implemented it on their hardware.

Quoted 8 lines

Quoted 7 lines

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?

Quoted 4 lines

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 :))

I am not sure how useful it is. I know IBM has tried in the past to get a similar feature introduced. I believe they settled on a ptrace extension to do direct user-to-user copies from within the kernel.

Quoted 2 lines

- Even if the answer to that is "no", should we maintain the feature in-tree rather than out-of-tree?

Not sure on the second one, but I believe Linus' objection is security and I can certainly understand that. Right now, SGI's xpmem implementation enforces that all jobs in the task need to have the same UID. There is no exception for root or and administrator.

Quoted 6 lines · On Thu, 14 Feb 2013 15:35:12 -0600 Robin Holt <[email protected]> wrote:

I am open to suggestions. Can you suggest existing kernel functionality that allows one task to map another virtual address space into their va space to allow userland-to-userland copies without system calls? If there is functionality that has been introduced in the last couple years, I could very well have missed it as I have been fairly heads-down on other things for some time.

That's conceptually very similar to mm/process_vm_access.c. process_vm_readv/writev do kernel-based copying rather than a direct mmap.

Quoted 18 lines

Quoted 2 lines

To what extent is all this specific to SGI hardware characteristics?

SGI's hardware allows two things, a vastly larger virtual address space and the ability to access memory in other system images on the same numa fabric which are beyond the processsors physical addressing capabilities.

I am fairly sure Cray has taken an older version of XPMEM and stripped out a bunch of SGI specific bits and implemented it on their hardware.

Quoted 8 lines

Quoted 7 lines

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?

Quoted 8 lines

Quoted 4 lines

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 :))

I am not sure how useful it is. I know IBM has tried in the past to get a similar feature introduced. I believe they settled on a ptrace extension to do direct user-to-user copies from within the kernel.

process_vm_readv/writev is from Christopher Yeoh@IBM.

Quoted 7 lines

Quoted 2 lines

- Even if the answer to that is "no", should we maintain the feature in-tree rather than out-of-tree?

Not sure on the second one, but I believe Linus' objection is security and I can certainly understand that. Right now, SGI's xpmem implementation enforces that all jobs in the task need to have the same UID. There is no exception for root or and administrator.

I'd have thought that the security processing of a direct map would be identical to those in process_vm_readv/writev?

If we were to add a general map-this-into-that facility which is available to and runs adequately on our typical machines, I assume your systems would need some SGI-specific augmentation?