On Fri, Feb 10, 2017 at 02:07:19PM -0800, Andy Lutomirski wrote: > > Ok, probably for the best albeit that is based on an inability to figure > > out how it could be done efficiently and a suspicion that if it could be > > done, the scheduler would be doing it already. > > > > FWIW, I am doing a bit of this. For remote CPUs that aren't currently > running a given mm, I just bump a per-mm generation count so that they > know to flush next time around in switch_mm(). I'll need to add a new > hook to the batched flush code to get this right, and I'll cc you on > that. Stay tuned. > Ok, thanks. > > [1] I could be completely wrong, I'm basing this on how people have > > behaved in the past during TLB-flush related discussions. They > > might have changed their mind. > > We'll see. The main benchmark that I'm relying on (so far) is that > context switches get way faster, just ping ponging back and forth. I > suspect that the TLB refill cost is only a small part. > Note that such a benchmark is not going to measure the TLB flush cost. In itself, this is not bad but I suspect that the applications that care about interference from TLB flushes by unrelated processes are not applications that are context-switch intensive. -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
