factors affecting context switch time

Hello,

Keyword: Jiffie

Study

Google for "Linux kernel Jiffie" or read

// moma

Thanks for the links , but it still does not answer as to what are the factors affecting context switch times ?

cpu arch ,

Yes

Yes

memory being used currently ?

Yes

You're welcome...

There are also a number of other factors:

Clock rate of the processor.

How much need to be saved/loaded to switch contexts.

Phase of the moon :-)

Day of the week :-)

I'm sorta hoping that this is a homework question and not a real project.

GS

Funny though it may sound it is a real project :) .. need to calculate context switch time for a comparitive performance analysis and going to use lmbench. It is a X vs Y situation where X and Y are both overheads. X in this case is the time spent in performing 2 context switches while Y is another piece of code which hope to measure using RTDSC instruction.

If i know what factors affect the context switch time , then can say at what times X is a greater overhead and at what time Y is more expensive.

vivekian

In comp.os.linux.development.system vivekian wrote in part:

CPU arch is probably the biggest factor. Many CPUs are _much_ faster than x86, mostly as a result of the horrible slowness of interrupt processing on traditional 8259 PIC processing. This could be much faster in a kernel compiled to use APIC.

If you're talking co-operative task switching, x86 may be reasonably fast.

Actual times will vary depending on cache state and how long the scheduler has to run.

-- Robert

part:

Are there any specific instances when the context switch times are relatively higher than the normal processing e.g. when the number of processes executing are high ? Are there any papers which discuss these issues ?

vivekian

In comp.os.linux.development.system vivekian wrote in part:

Linux recently switched to an O(1) scheduler. You should be able to find quite some discussion about it's performance.

-- Robert

Yes will look it up . Btw , are there any architechtures which are known to have slow context switch times ?

Thanks again , vivekian

If you only look at context switch time (i.e. measure the time it takes from the last instruction in one one process to the first instruction in another), you get only half of the picture.

There is also considerable overhead resulting from having to flush TLB and caches during context switch, but this sort of overhead doesn't manifest itself as a discrete amount of time where the CPU does not execute user code. Instead it slows down execution of user code, because the CPU has to do page table walks and cache refills along the way.

The x86, for example, needs to flush the TLB for every switch of address space (i.e. process) while other archs (such as PowerPC & MIPS) have a "tagged TLB" which makes this unnecessary. The ARM architecture (at least up to the SA1100, don't know about the newer ones) needs to flush caches during address space switch.

Here is an IMHO interesting paper on (part of) the subjet

HTH

Rob

-- Robert Kaiser email: rkaiser AT sysgo DOT com SYSGO AG

if you can and do read, it helps you to answer your questions yourself.

Just playing devil's advocate here - if your application is likely to be that sensitive to context switch time then maybe you need to think more about its overall architecture. After all contest switch time ought to be a second order effect in a robust design.

Ian

Thanks robert. That is an interesting insight and lends a lot of weight against the context switches argument . Still wondering though is this ARM , x86 specific ? My report needs to take into consideration real time systems and wonder if this would effect architechtures which are meant for real time processing , since they are mostly MMU less .

vivekian

Windows :)

-Michael

Supposedly most important factor: count of CPUs

-Michael

Not with Linux since the kernel is mapped into each process' address space and the page tables do not change for system calls returning to the same process.

Another paper on fast address space switching on ARM which you may find interesting:

Yes. The Cache/TLB structure is very archtecture specific. For example, the problem with the ARM cache, IIRC, is that uses virtual addesses to identify cache lines, so, if the mappings are changed, all entries must be flushed. The x86 uses physical addresses instead, which are independent of the current mappings. Likewise, the x86 MMU does not support any tags on TLB entries, so, when switching between address spaces, the TLB must be flushed, whereas with PPC or MIPS, you just need to load the tag that identifies the current address space into some register.

OK, I was assuming that a context switch includes an address space switch. With no MMU, everything runs in one common address space, of course, so a TLB or Cache flush would not be necessary for a context switch with any of the mentioned architectures.

That said, there are quite a few real time systems that do use the MMU, mainly to provide protection between programs.

Cheers

Rob

-- Robert Kaiser email: rkaiser AT sysgo DOT com SYSGO AG

That is interesting. Bcos I see an increase in L1 and L2 cache misses with the increase in the number of system calls I make for x86 architecture. The system is running the bare minimum kernel processes necessary. The read call uses the same buffer in the tight loop. The buffer is page aligned.

I am tak> "vivekian" wrote: