0
votes

There are plenty of programs available which can be used to calculate context switch time from user-space. But all of these have several overhead - like overhead of clock_gettime() timer, overhead of read/write operation in pipe.

Is it possible to measure context switch time in Linux kernel space where above overhead won't be there?

May be TWO GLOABL VARIABLES can be added in kernel module which will store the time when context_switch function is called , the time when context_switch is finished.

The challenges I am facing with this approach is context switch function can be called by any process and from any core.

Is it feasible or advisable to add something to struct task_struct or struct rq ?

I am using Ubuntu 16.04 OS .

1
What exactly do you mean by context switch? Does that include a single process calling getpid (or similarly trivial system call) -- switching from user mode to kernel mode and back? Handling a trivial interrupt and returning to user mode? Switching between 2 different processes on the same core? How about 2 different threads of the same process? It's difficult to measure these in part because there are so many initial and subsequent contexts to which one might switch, and hence many different attributes which might be affected by the switch, all of which have effects on the measured time. - Gil Hamilton
There will always still be overhead in measuring the time something takes. It may be reduced in kernel mode due to not needing the user-mode to kernel transition of a syscall to obtain the time. If you just want to measure how long it takes to do a system call, say, you can (from user-mode) simply lock your process to a single core (with sched_setaffinity), then use the x86 timestamp counter (assembly RDTSC instruction) to measure elapsed time. That has very little overhead. But then of course you'll need to scale that according to the CPU clock speed to turn it in seconds. - Gil Hamilton
context switch time between two process or between two threads. I am only concerned when Process-A/Thread-A releases CPU and Process-B/Thread-B gets the CPU, not for the system call . - bholanath
Switching between two different threads of same process running in same CPU core. Switching between two different process running in same CPU core. - bholanath

1 Answers

0
votes

if you want to check the delay on context switch between threads (not including thread execution time) :

based on kernel config, you can refer to

  • __schedule : scheduler main API
  • preempt_schedule_common
  • schedule
  • preempt_schedule_context
  • preempt_schedule_irq

However, it would be hard to calculate the exact delay since entire scheduling functionality doesn't seem to protected by spinlock_irq_disable() context. If you don't disable "local interrupt", your delay calculation will include ISR serving time.

__schedule is disabling local_irq for some specific critical section. Anyway, core part of scheduling is __schedule() API.