最近在复习Linux内核进程操作 schedule的时候,看到这个RDTSC指令,从字面上看 是机器从启动开后的运行的指令周期数,
查了下英文说明:
RDTSC―Read Time-Stamp Counter
Opcode Instruction Description
0F 31 RDTSC Read time-stamp counter into EDX:EAX
Description
Loads the current value of the processor’s time-stamp counter into the EDX:EAX registers. The
time-stamp counter is contained in a 64-bit MSR. The high-order 32 bits of the MSR are loaded
into the EDX register, and the low-order 32 bits are loaded into the EAX register. The processor
increments the time-stamp counter MSR every clock cycle and resets it to 0 whenever the
processor is reset.
The time stamp disable (TSD) flag in register CR4 restricts the use of the RDTSC instruction.
When the TSD flag is clear, the RDTSC instruction can be executed at any privilege level; when
the flag is set, the instruction can only be executed at privilege level 0. The time-stamp counter
can also be read with the RDMSR instruction, when executing at privilege level 0.
The RDTSC instruction is not a serializing instruction. Thus, it does not necessarily wait until
all previous instructions have been executed before reading the counter. Similarly, subsequent
instructions may begin execution before the read operation is performed.
This instruction was introduced into the IA-32 Architecture in the Pentium processor.
Operation
IF (CR4.TSD ← 0) OR ((CR4.TSD ← 1) AND (CPL=0))
THEN
EDX:EAX ← TimeStampCounter;
ELSE (* CR4 is 1 and CPL is 1, 2, or 3 *)
#GP(0)
FI;
Flags Affected
None.
Protected Mode Exceptions
#GP(0) If the TSD flag in register CR4 is set and the CPL is greater than 0.
Real-Address Mode Exceptions
#GP If the TSD flag in register CR4 is set.
Virtual-8086 Mode Exceptions
#GP(0) If the TSD flag in register CR4 is set.
在进程调度和切换过程中,在SMP环境下,需要关注的各CPU的运行情况,下面的内核代码标识获取当前CPU的last_reschedule:
/*
* Standard way to access the cycle counter on i586+ CPUs.
* Currently only used on SMP.
*
* If you really have a SMP machine with i486 chips or older,
* compile for that, and this will just always return zero.
* That's ok, it just means that the nicer scheduling heuristics
* won't work for you.
*
* We only use the low 32 bits, and we'd simply better make sure
* that we reschedule before that wraps. Scheduling at least every
* four billion cycles just basically sounds like a good idea,
* regardless of how fast the machine is.
*/
typedef unsigned long long cycles_t;
extern cycles_t cacheflush_time;
static inline cycles_t get_cycles (void)
{
#ifndef CONFIG_X86_TSC
return 0;
#else
unsigned long long ret;
rdtscll(ret);
return ret;
#endif
}