Linux clock handling mechanism

3 software clock handling here said "software clock" refers to software timer (SoftwareTimers), is a software concept is built on the hardware clock.

It records the future one time operation to be performed (a function), and allows the true when that moment comes, these operations (function) can be executed on time. For example: it is like living in the alarm, set the alarm ringing time (next time), when the time (the equivalent of the hardware clock) update to the ring of time, the alarm will ring. The ringing time is like the expiration time of the software clock, ringing the action like software clock after expiration of the function to be executed, and the alarm time updates like the hardware clock's updates. Implementing software clock principle is simple: each time the hardware clock interrupt when they arrive, kernel update of jiffies before and the expiration time of the software clock. If jiffies equal to or greater than the expiration time of the software clock, the kernel performs a specified function software clock. The following sections detail how implementing software Linux2.6.25 clock. 3.1 related data structure structtimer_list: software clock, documented the expiration time of the software clock, as well as the expiry of the action to perform. The specific meaning of members, as well as shown in table 3-1. Structtvec_base: for organizations, the structure of the management software clock. On SMP systems, one for each CPU. Specific members, as well as meaning see table 3-2. Table 3-key members of the domain name type 1structtimer_list describes the linked list entrystructlist_head expiresunsignedlong due to tick for functionvoid (*) (unsignedlong) callback function, expires do dataunsignedlong parameter of the callback function records the basestructtvec_base * software clock resides structtvec_base variable table 3-2structtvec_base type's members domain name type describes lockspinlock_t used to synchronize operations running_timerstructtimer_list * working software clock timer_jiffiesunsignedlong currently processing software clock expiration time tv1structtvec_root saved due from timer_jiffies to timer_jiffies + (including edge value) of all software clock tv2structtvec saved the expiration time from timer_jiffies + to timer_jiffies + (including edge value) of all software clock tv3structtvec saved the expiration time from timer_jiffies + to timer_jiffies + (including edge value) of all software clock tv4structtvec saved the expiration time from timer_jiffies + to timer_jiffies + (including edge value) of all software clock tv5structtvec saved the expiration time from timer_jiffies + to timer_jiffies + (including edge value) of all software clock which is of type structtvec_root tv1, tv2 ~ tv5 is of type structtvec, listing 3-1 shows their definitions list 3-definition of 1structtvec_root and structtvec structtvec {structlist_headvec [TVN_SIZE];}; structtvec_root{structlist_headvec[TVR_SIZE];}; Visible they are actually a type of array structlist_head TVN_SIZE and TVR_SIZE in system is not configured when macro CONFIG_BASE_SMALL respectively defined as 64 and 256. 3.2 data structure diagrams between 3-1 shows the relationships between data structures: from the diagram it is clear: the software clock (structtimer_list, in the figure indicated by a timer) to two-way linked list (structlist_head) form, in accordance with their expiration time save the corresponding barrel (tv1 ~ tv5). Tv1 saved relative to under 256 timer_jiffies tick time expiration of all the software clock, tv2 in saved relative to timer_jiffies under 256 * 64 tick time expiration of all the software clock; tv3 in saved relative to timer_jiffies under 256 * 64 * 64 tick time expiration of all the software clock, tv4 in saved relative to timer_jiffies 256 * under 64 * 64 * 64 tick time expiration of all the software clock, tv5 saved relative to timer_jiffies under 256 * 64 * 64 * 64 * 64 tick time expiration of all the software clock. In particular, from a static perspective, suppose timer_jiffies is 0, then the tv1 [0] holds the current expiration (expiration time equals timer_jiffies) software clock (need to be processed at once), tv1 [1] holds the next tick arrives, expiration of all the software clock, tv1 [n] (0 <><=255）保存着下n个tick到达时，到期的>All software clock. And tv2 [0] holds the following 256 to 511 tick all the software clock between maturity, tv2 [1] holds the following 512 to 767 a tick all of the software expires between the clock, tv2 [n] (0 <><=63）保存着下256*(n+1)到256*(n+2)-1个tick之间到达的所有软件时钟。> Tv3 ~ tv5 and so on. Note: a tick length refers to two hardware clock interrupt occurred between the time interval from the above description can be seen: the software clock is in accordance with their expiration time relative to the current processing software clock of expiration time (numerical timer_jiffies) saved in structtvec_base variables. But the expiration time of the maximum relative (expiration time-timer_jiffies) 0xffffffffUL (tv5 last element to indicate the relative expiry time of maximum). Also note that the software clock processing is local to the CPU, so on SMP systems each CPU is saved to a variable of type structtvec_base, used to organize and manage the software clock CPU. From the chart you can see structtvec_base variable is per-CPU (on the principle of variable per-CPU and use see references). As a result of subsequent explanation often refer to each CPU-related structtvec_base variables, so in order to facilitate that save software clock structtvec_base variable is the software base of the clock, or CPU base.