Re: Move to unshared VMAs in NOMMU mode?

[Hugh Dickins <hugh@veritas.com>]

On Fri, 9 Mar 2007, David Howells wrote:
> 
> I've been considering how to deal with the SYSV SHM problem, and I think we
> may have to move to unshared VMAs in NOMMU mode to deal with this.  Currently,
> what we have is each mm_struct has in its arch-specific context argument a
> list of VMLs.  Take the FRV context for example:
>... 
> Another way of dealing with the nattch count on NOMMU systems is to do it
> through the VML list, but that then needs more special casing in the SHM
> driver and perhaps others.
> 
> Thoughts?

Thoughts are in regrettably short supply at my end.

I do appreciate all the trouble you've taken to explain it,
in terms I'd understand.  And the way you've taken on board
my anxiety about vma assumptions diverging between NO/MMU.

But if "the SYSV SHM problem" you mention at the beginning
is just the "nattch" problem you mention at the end, I doubt
that's worth such a redesign as you're considering here.

Actually, I'm rather surprised SHM needs any such nattch count,
I'd expect it to deducible from file->f_count and mode&SHM_DEST
(but haven't investigated whether that really works out at all).

If you just need a little CONFIG_MMU in ipc/shm.c to solve your
problem, I don't think more is justified.

Your struct vm_region idea does look more to my taste than what
you presently have; yet if you pursue it, I think it would just
make divergence worse wouldn't it?  NOMMU wanting vma to contain
a pointer to vm_region, MMU wanting vm_region embedded in vma.

I don't really understand why NOMMU chooses to share vmas, or
vm_regions, rather than just sharing the data which they indicate.
Just because you can use less memory that way?  But no need to
justify it now, I'm unlikely to study it in detail.

Hugh