Re: [uml-devel] Re: The SKAS4 patch?? + ideas for 0 context-switch

[BlaisorBlade <blaisorblade_spam@yahoo.it>]

Alle 06:55, martedì 8 giugno 2004, Jeff Dike ha scritto:
> blaisorblade_spam@yahoo.it said:

> > In detail (skip this if you got what I mean): to do a syscall, without
> > SYSEMU  there is a CS to the guest kernel (which invalidates tons of
> > TLBs, i.e. is  the heavier of all ones) + a few instruction + the two
> > useless CS's deleted  by SYSEMU, which invalidate a very few TLB
> > entries (I think that only 1-2  pages of code + data will have be
> > accessed) + the syscall execution (using a  lot of memory) + the final
> > context switch to the userspace program, which  will now take a lot of
> > time to refill its TLB.
>
> On x86, which doesn't have tagged TLBs IIRC, there has to be a full tlb
> flush no matter how large the processes involved in the switch.

Sorry, what are tagged TLBs? x86 can flush, on some processors, just some 
TLBs, but for process switch you must flush everything.

Or better, if "tagged TLBs" means that the processor knows with which process 
a TLB is associated, then I understand what you mean and agree with you.

>  What I'm
> not clear on is whether small full flushes are faster than big ones.

Ok, something more definite on this:

http://kerneltrap.org/node/view/2891

the 4G/4G patch creates a situation similar to the current one (without my 
approach) for UML - but they here speak about number-crunching, i.e. only 
about the cost of the interrupt handler, which is ran HZ (= 1000) times per 
second:

"> [*] a nitpick: you keep saying '2000 tlb flushes per second'. This is
>     misleading, there's one flush of the userspace TLBs every 1 msec
>     (i.e. 1000 per second), and one flush of the kernel TLBs - but
>     the kernel TLBs are small at this point, especially with 4MB pages.

I'm saying 2000 tlb flushes only because I'd be wrong saying there are only
1000, but I obviously agree the cost of half of them is not significant (the
footprint of the irq handler is tiny)."

I.e. they (Andrea Arcangeli and Ingo Molnar) agree that the cost of a TLB 
flush changes depending on the number of filled TLBs. And they seem to also 
agree that there is a "secondary cost", the cost of the TLB misses (which is 
IMHO the one which changes depending on how much entries you flush).

See also the benchmark I post (host vs UML with SYSEMU), which show that there 
is an doubling in user time due to executing getpid() vs non executing it, 
while looping over 64 pages (64 pages should mean that the TLB never faults): 
the increase in user time, which is spent mostly by looping onto pages, is 
due to the TLB misses.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel