Re: Move to unshared VMAs in NOMMU mode?

[David Howells]

Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:

> As I understand your description for non-shared mappings the VMAs are
> per process.

Are you talking about the current state of play?  If so, not precisely.  In
the current scheme of things, *all* VMAs are kept in a global tree and are
globally available; it's just that any VMA that's not shareable will not be
shared, and so, in effect, is per-process.

In my suggested revamp, VMAs revert to being per-process objects only, and
sharing is effected by indirection.

> For shared mappings you share in some sense the page cache.

Currently, no - not unless the driver does something clever as ramfs does.
Sharing through the page cache is a nice idea, but it has some limitations,
mainly that non-sharing then operates differently.

> My gut feel says just keep a vma per process of the regions the
> process has and do the appropriate book keeping and all will be fine.

I'm sure it will be, but at the cost of consuming extra memory.  I'm not sure
that the amount of extra memory is, however, all that significant.  Now that I
think about it, I don't imagine that a lot of processes are going to be
running at once on a NOMMU system, and so the scope for sharing isn't all that
wide.

> For shm_nattach it looks like you simply are not calling the
> open/close methods on fork (because you have a shared pool of vmas).

There is no fork.

No, the problem is that sys_shmat() relies on do_mmap_pgoff() to call the VMA
open() method.  However, this assumes that a new VMA will be made per process.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/