Re: Potential race in TLB flush batching?

[Nadav Amit <nadav.amit@gmail.com>]

Mel Gorman <mgorman@suse.de> wrote:

> On Thu, Jul 27, 2017 at 04:04:20PM +0900, Minchan Kim wrote:
>>> There is one issue I forgot: pte_accessible() on x86 regards
>>> mm_tlb_flush_pending() as an indication for NUMA migration. But now the code
>>> does not make too much sense:
>>> 
>>>        if ((pte_flags(a) & _PAGE_PROTNONE) &&
>>>                        mm_tlb_flush_pending(mm))
>>> 
>>> Either we remove the _PAGE_PROTNONE check or we need to use the atomic field
>>> to count separately pending flushes due to migration and due to other
>>> reasons. The first option is safer, but Mel objected to it, because of the
>>> performance implications. The second one requires some thought on how to
>>> build a single counter for multiple reasons and avoid a potential overflow.
>>> 
>>> Thoughts?
>> 
>> I'm really new for the autoNUMA so not sure I understand your concern
>> If your concern is that increasing places where add up pending count,
>> autoNUMA performance might be hurt. Right?
>> If so, above _PAGE_PROTNONE check will filter out most of cases?
>> Maybe, Mel could answer.
> 
> I'm not sure what I'm being asked. In the case above, the TLB flush pending
> is only relevant against autonuma-related races so only those PTEs are
> checked to limit overhead. It could be checked on every PTE but it's
> adding more compiler barriers or more atomic reads which do not appear
> necessary. If the check is removed, a comment should be added explaining
> why every PTE has to be checked.

I considered breaking tlb_flush_pending to two: tlb_flush_pending_numa and
tlb_flush_pending_other (they can share one atomic64_t field). This way,
pte_accessible() would only consider “tlb_flush_pending_numa", and the
changes that Minchan proposed would not increase the number unnecessary TLB
flushes.

However, considering the complexity of the TLB flushes scheme, and the fact
I am not fully convinced all of these TLB flushes are indeed unnecessary, I
will put it aside.

Nadav
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>