Re: mmap'ed memory in core files ?

[Hugh Dickins]

On Fri, 4 Jul 2008, Stefan Richter wrote:
> Hidehiro Kawai wrote:
> > Philippe De Muyter wrote:
> > >
> > > As I don't know the real meaning of VM_RESERVED, I do not know which
> > > choice
> > > is the best one for the official kernel tree,
> 
> I don't know these things either.  But among else, VM_RESERVED prevents a vma
> from being swapped out.  Makes kind of sense, given that besides the CPUs also
> the FireWire controller writes to this memory.
> 
> > > but locally I'll go for
> > > adding VM_ALWAYSDUMP in ieee1394::dma_region_mmap.
> > 
> > I'm afraid I don't know real usages of VM_RESERVED and VM_IO, either.

They're rather an embarrassment, nobody can say quite what VM_RESERVED
and VM_IO really mean, beyond not-your-ordinary-vma: VM_VOODOO, beware.
They both say "count me as reserved_vm", which means /proc/<pid>/status
leaves them out of VmSize.

Certainly VM_IO hints at special I/O memory, but in most cases there's
nothing very special about either: just memory preallocated by a driver.

In 2.4 VM_RESERVED indeed prevented swapout from looking at the pages
of that vma.  We probably ought to have killed it as part of the 2.5
switch to rmap.  In 2.6 the pages of a VM_RESERVED vma wouldn't be
considered for swapout, because they're not put on any LRU for that.
I think I promised (ah, that's a shameful phrase!) to get rid of it
a few years ago, but never quite got around to it.

VM_RESERVED and VM_IO are treated as equivalent in most tests, but
there's just a few places, e.g. get_user_pages, where we're scared
off by VM_IO but don't mind VM_RESERVED.

VM_ALWAYSDUMP: marvellous, a flag with an understandable name and
a clear purpose.

Hugh
--
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/