Re: [PATCH v3] Optimise TLB flush for kernel mm in UML

From: Richard Weinberger <richard@nod.at>
To: Anton Ivanov <anton.ivanov@kot-begemot.co.uk>
Cc: linux-um@lists.infradead.org
Subject: Re: [PATCH v3] Optimise TLB flush for kernel mm in UML
Date: Sat, 06 Oct 2018 23:15:25 +0200	[thread overview]
Message-ID: <1764739.0Z0hY7T85t@blindfold> (raw)
In-Reply-To: <83f296bd-feb1-5177-228e-f294aa22fa5f@kot-begemot.co.uk>

Am Samstag, 6. Oktober 2018, 23:04:08 CEST schrieb Anton Ivanov:
> On 06/10/2018 21:38, Richard Weinberger wrote:
> > Anton,
> >
> > Am Donnerstag, 4. Oktober 2018, 19:25:10 CEST schrieb anton.ivanov@cambridgegreys.com:
> >> From: Anton Ivanov <anton.ivanov@cambridgegreys.com>
> >>
> >> This patch introduces bulking up memory ranges to be passed to
> >> mmap/munmap/mprotect instead of doing everything one page at a time.
> >>
> >> This is already being done for the userspace UML portion, this
> >> adds a simplified version of it for the kernel mm.
> >>
> >> This results in speed up of up to 10%+ in some areas (sequential
> >> disk read measured with dd, etc).
> > Nice!
> > Do you have also data on how much less memory mappings get installed?
> 
> 
> Not proper statistics. I had some debug printks early on and instead of 
> single pages I was seeing a few hundred Kbytes at a time being mapped in 
> places. I can try a few trial runs with some debug printks to collect stats.
> 
> >
> >> Add further speed-up by removing a mandatory tlb force flush
> >> for swapless kernel.
> > It is also not entirely clear to me why swap is a problem here,
> > can you please elaborate?
> 
> I asked this question on the list a while back.
> 
> One of the main remaining huge performance bugbears  in UML which 
> accounts for most of its "fame" of being slow is the fact that there is 
> a full TLB flush every time a fork happens in the UML userspace. It is 
> also executed with force = 1.
> 
> You pointed me to an old commit from the days svn was being used which 
> was fixing exactly that by introducing the force parameter.
> 
> I tested force on/off and the condition that commit is trying to cure 
> still stands. If swap is enabled the tlb flush on fork/exec needs to 
> have force=1. If, however, there is no swap in the system the force is 
> not needed. It happily works without it.
> 
> Why - dunno. I do not fully understand some of that code.

Okay, I hoped you figured in the meanwhile.
Seems like we need to dig deeper in the history.

Thanks,
//richard

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um