Re: scalable kmap (was Re: vm lock contention reduction)

Andrew Morton
2002-07-08T20:39:04Z

Andrea Arcangeli wrote:
>
> ...
> > generic_file_write()
> > {
> > ...
> > atomic_inc(&current->mm->dont_unmap_pages);
> >
> > {
> > volatile char dummy;
> > __get_user(dummy, addr);
> > __get_user(dummy, addr+bytes+1);
> > }
> > lock_page();
> > ->prepare_write()
> > kmap_atomic()
> > copy_from_user()
> > kunmap_atomic()
> > ->commit_write()
> > atomic_dec(&current->mm->dont_unmap_pages);
> > unlock_page()
> > }
> >
> > and over in mm/rmap.c:try_to_unmap_one(), check mm->dont_unmap_pages.
> >
> > Obviously, all this is dependent on CONFIG_HIGHMEM.
> >
> > Workable?
>
> the above pseudocode still won't work correctly,

Sure. It's crap. It can be used to get mlockall() for free.

> if you don't pin the
> page as Martin proposed and you only rely on its virtual mapping to stay
> there because the page can go away under you despite the
> swap_out/rmap-unmapping work, if there's a parallel thread running
> munmap+re-mmap under you. So at the very least you need the mmap_sem at
> every generic_file_write to avoid other threads to change your virtual
> address under you. And you'll basically need to make the mmap_sem
> recursive, because you have to take it before running __get_user to
> avoid races. You could easily do that using my rwsem, I made two versions
> of them, with one that supports recursion, however this is just for your
> info, I'm not suggesting to make it recursive.

I think I'll just go for pinning the damn page. It's a spinlock and
maybe three cachelines but the kernel is about to do a 4k memcpy
anyway. And get_user_pages() doesn't show up much on O_DIRECT
profiles and it'll be a net win and we need to do SOMETHING, dammit.

> ...
> The only reason I can imagine rmap useful in todays
> hardware for all kind of vma (what the patch provides compared to what
> we have now) is to more efficiently defragment ram with an algorithm in
> the memory balancing to provide largepages more efficiently from mixed
> zones, if somebody would suggest rmap for this reason (nobody did yet)

It has been discussed. But no action yet.

> I
> would have to agree completely that it is very useful for that, OTOH it
> seems everybody is reserving (or planning to reserve) a zone for
> largepages anyways so that we don't run into fragmentation in the first
> place. And btw - talking about largepages - we have three concurrent and
> controversial largepage implementations for linux available today, they
> all have different API, one is even shipped in production by a vendor,

What implementation do you favour?

> and while auditing the code I seen it also exports an API visible to
> userspace [ignoring the sysctl] (unlike what I was told):
>
> +#define MAP_BIGPAGE 0x40 /* bigpage mapping */
> [..]
> _trans(flags, MAP_GROWSDOWN, VM_GROWSDOWN) |
> _trans(flags, MAP_DENYWRITE, VM_DENYWRITE) |
> + _trans(flags, MAP_BIGPAGE, VM_BIGMAP) |
> _trans(flags, MAP_EXECUTABLE, VM_EXECUTABLE);
> return prot_bits | flag_bits;
> #undef _trans
>
> that's a new unofficial bitflag to mmap that any proprietary userspace
> can pass to mmap today. Other implementations of the largepage feature
> use madvise or other syscalls to tell the kernel to allocate
> largepages. At least the above won't return -EINVAL so the binaryonly
> app will work transparently on a mainline kernel, but it can eventually
> malfunction if we use 0x40 for something else in 2.5. So I think we
> should do something about the largepages too ASAP into 2.5 (like
> async-io).

Yup. I don't think the -aa kernel has a large page patch, does it?
Is that something which you have time to look into?

-