Re: [RFC PATCH 6/6] powerpc/kvm: change the condition of identifying hugetlb vm

Hi Scott

I understand what you said.

I will use the function 'is_vm_hugetlb_page()' to hide the bit
combinations according to your comments in the next version of patch
set.

But for the situation like below, there isn't an obvious structure
'vma', using 'is_vm_hugetlb_page()' maybe costly or even not possible.
void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
                unsigned long end, unsigned long vmflag)
{
    ...

    if (end == TLB_FLUSH_ALL || tlb_flushall_shift == -1
                    || vmflag & VM_HUGETLB) {
        local_flush_tlb();
        goto flush_all;
    }
...
}


Thank you
Wenwei

2015-07-07 5:34 GMT+08:00 Scott Wood [off-list ref]:

On Fri, 2015-07-03 at 16:47 +0800, wenwei tao wrote:

quoted

Hi Scott

Thank you for your comments.

Kernel already has that function: is_vm_hugetlb_page() , but the
original code didn't use it,
in order to keep the coding style of the original code, I didn't use it
either.

For the sentence like: "vma->vm_flags & VM_HUGETLB" , hiding it behind
'is_vm_hugetlb_page()' is ok,
but the sentence like: "vma->vm_flags &
(VM_LOCKED|VM_HUGETLB|VM_PFNMAP)" appears in the patch 2/6,
is it better to hide the bit combinations behind the
is_vm_hugetlb_page() ?  In my patch I just replaced it with
"vma->vm_flags & (VM_LOCKED|VM_PFNMAP) ||  (vma->vm_flags &
(VM_HUGETLB|VM_MERGEABLE)) == VM_HUGETLB".

If you're going to do non-obvious things with the flags, it should be done in
one place rather than throughout the code.  Why would you do the above and
not "vma->vm_flags & (VM_LOCKED | VM_PFNMAP) || is_vm_hugetlb_page(vma)"?

-Scott