Re: Question about process.c

[Richard Weinberger <richard@sigma-star.at>]

Anton,

Am Dienstag, 1. Mai 2018, 15:48:48 CEST schrieb Anton Ivanov:
> arch/um/kernel/process.c line 140 invokes force_flush_all();
> 
> which does a full tlb flush with the force flag set.
> 
> I did a quick test and I did not notice any breakage if we replace that 
> with a quickly hacked together new function called gentle_flush_all() 
> which does the same but without setting the force flag in the tlb routines.
> 
> At the same time I got 10% or better speedup for fork-heavy things like 
> startup, etc.
> 
> In fact, this is one of the last remaining major performance bugbears. 
> We got most of the other stuff to a very reasonable standard - 
> networking, disk, etc is not that far off from let's say qemu and the 
> overall "slowness" is now mostly down to the huge cost of fork/exec.
> 
> Example (ab)using busybox. Busybox executes cat passed as the find -exec 
> argument internally shortcutting to its applet. As a result there is no 
> cost of fork/exec incurred when we run a find -exec cat {} via busybox. 
> Normal find executes /bin/cat instead.
> 
> This allows us to compare and attribute the cost of fork/exec in scripts 
> as well as gives us a benchmark to see the effect of any changes.
> 
> Bare metal:
> 
> aivanov@amistad:/var/autofs/local/src/linux-work/linux-submit$ time 
> busybox find /mnt/usr -type f -exec cat {} > /dev/null \;
> 
> real    0m16.511s
> user    0m12.672s
> sys    0m4.001s
> aivanov@amistad:/var/autofs/local/src/linux-work/linux-submit$ time find 
> /mnt/usr -type f -exec cat {} > /dev/null \;
> 
> real    0m25.329s
> user    0m16.397s
> sys    0m9.185s
> 
> UML:
> 
> root@uml-switch:~# time busybox find /usr -type f -exec cat {} > 
> /dev/null \;
> 
> real    0m11.447s
> user    0m0.000s
> sys    0m8.820s
> root@uml-switch:~# time find /usr -type f -exec cat {} > /dev/null \;
> 
> real    7m8.228s
> user    0m0.000s
> sys    6m42.780s
> 
> The filesystem is identical in both cases. The experiment is not 
> perfectly "clean" as i am doing other stuff on my laptop, but it is 
> reasonably indicative
> 
> In fact, in the longer term I would really like to somehow speed-up most 
> of the stuff tlb.c It is painfully slow at present.

Hmmm, not sure. I fear without going deep into the UML history we cannot know.
I think we have to do a full flush for security reasons.

Thanks,
//richard

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y

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