Messages in this thread | | | From | KOSAKI Motohiro <> | Subject | Re: [PATCH] mm: make munlock fast when mlock is canceled by sigkill | Date | Wed, 26 Aug 2009 11:32:43 +0900 (JST) |
| |
> > > Yeah, GUP_FLAGS_NOFAULT is better. > > > > Me too. > > I will change this flag name. > >... > > When I try to change __get_user_pages(), I got problem. > > If remove NULLs from pages, > > __mlock_vma_pages_range() cannot know how long __get_user_pages() readed. > > So, I have to get the virtual address of the page from vma and page. > > Because __mlock_vma_pages_range() have to call > > __get_user_pages() many times with different `start' argument. > > > > I try to use page_address_in_vma(), but it failed. > > (page_address_in_vma() returned -EFAULT) > > I cannot find way to solve this problem. > > Are there good ideas? > > Please give me some ideas. > > I agree that this munlock issue needs to be addressed: it's not just a > matter of speedup, I hit it when testing what happens when mlock takes > you to OOM - which is currently a hanging disaster because munlock'ing > in the exiting OOM-killed process gets stuck trying to fault in all > those pages that couldn't be locked in the first place.
I agree too.
> I had intended to fix it by being more careful about splitting/merging > vmas, noting how far the mlock had got, and munlocking just up to there. > However, now that I've got in there, that looks wrong to me, given the > traditional behaviour that mlock does its best, but pretends success > to allow for later instantiation of the pages if necessary. > > You ask for ideas. My main idea is that so far we have added > GUP_FLAGS_IGNORE_VMA_PERMISSIONS (Kosaki-san, what was that about? > we already had the force flag),
MAY_WRITE and MAY_READ might be turned off at some special case. but munlock should turn off PG_mlock bit. otherwise the page never be reclaimed. This problem was explained by Lee about a year ago.
However, To use follow_page() solove this issue and we will be able to remove this ugly flag.
> GUP_FLAGS_IGNORE_SIGKILL, and now you propose > GUP_FLAGS_NOFAULT, all for the sole use of munlock. > > How about GUP_FLAGS_MUNLOCK, or more to the point, GUP_FLAGS_DONT_BE_GUP? > By which I mean, don't all these added flags suggest that almost > everything __get_user_pages() does is unsuited to the munlock case? > > My advice (but I sure hate giving advice before I've tried it myself) > is to put __mlock_vma_pages_range() back to handling just the mlock > case, and do your own follow_page() loop in munlock_vma_pages_range().
Agreed. follow_page() is better.
| |