On Mon 06-08-18 13:48:35, Yang Shi wrote:

On 8/6/18 1:41 PM, Michal Hocko wrote:

quoted

On Mon 06-08-18 09:46:30, Yang Shi wrote:

quoted

On 8/6/18 2:40 AM, Michal Hocko wrote:

quoted

On Fri 03-08-18 14:01:58, Yang Shi wrote:

quoted

On 8/3/18 2:07 AM, Michal Hocko wrote:

quoted

On Fri 27-07-18 02:10:14, Yang Shi wrote:

[...]

quoted

quoted

quoted

quoted

quoted

If the vma has VM_LOCKED | VM_HUGETLB | VM_PFNMAP or uprobe, they are
considered as special mappings. They will be dealt with before zapping
pages with write mmap_sem held. Basically, just update vm_flags.

Well, I think it would be safer to simply fallback to the current
implementation with these mappings and deal with them on top. This would
make potential issues easier to bisect and partial reverts as well.

Do you mean just call do_munmap()? It sounds ok. Although we may waste some
cycles to repeat what has done, it sounds not too bad since those special
mappings should be not very common.

VM_HUGETLB is quite spread. Especially for DB workloads.

Wait a minute. In this way, it sounds we go back to my old implementation
with special handling for those mappings with write mmap_sem held, right?

Yes, I would really start simple and add further enhacements on top.

If updating vm_flags with read lock is safe in this case, we don't have to
do this. The only reason for this special handling is about vm_flags update.

 
Yes, maybe you are right that this is safe. I would still argue to have
it in a separate patch for easier review, bisectability etc...

-- 
Michal Hocko
SUSE Labs