 Messages in this thread SubjectRe: [PATCH v4 3/7]
x86/flush_tlb: try flush_tlb_single one by one in
flush_tlb_range  > Ok, question: > we're comparing TLB size with
the amount of pages mapped by this mm > struct. AFAICT, that
doesn't mean that all those mapped pages do have > respective
entries in the TLB, does it? > If so, then the actual entries
number is kinda inaccurate, no? We don't > really know how many
TLB entries actually belong to this mm struct. Or am I > missing
something?  No, we can not know the exactly TLB entires for. But
usually, when you process is doing the mprotect/munmap etc
system call, your process has taken much of memory and already
filled lots of TLB entries.  This point is considered imply in
the balance point calculation. checking following equation X(TLB
flush entries) * 100ns(assumed invlpg cost)  The X value we got
is far lower then theory value. That means remain TLB entries is
may not so much, or TLB refill cost is much lower due to
hardware pre-fetcher.   >> + if ((end - sta