Section 19.1. The System Clock Thread

19.1. The System Clock Thread

The Solaris clock thread performs routine processing as a lock-level client of the cyclic subsystem (Section 19.4). For example, it triggers the dispatcher to recalculate thread priorities at regular intervals, and also initiates callout queue processing. Figure 19.1 shows the interaction between the system timing interfaces and subsystems.

Figure 19.1. Clock and Timer Interactions

The kernel installs a cyclic to call the clock thread at regular intervals, by default 100 times per second. With each clock interrupt, a handler is entered. It performs the following functions:

• Sets available kernel anon space (anon_free) value, for tracking and reporting.

• Sets free memory (freemem) value, for tracking and reporting.

• Adjusts the time-of-day clock for possible jitter.

• Calculates system dispatch (run queue) queue size.

• Does clock-tick processing for the thread running on the CPU (except the CPU running the clock interrupt thread) and threads that are exiting. Note that kernel threads that do not have an associated LWPthat is, kernel service threads that are an integral part of the operating systemare not subject to tick processing.

• Updates the lbolt counter. lbolt counts the number of clock ticks since boot.

• Processes the kernel callout table (described in Section 19.2).

• Wakes up any threads waiting for the kernel cage resize.

• If on a one-second interval, calculates kernel swap parameters (free, reserved, and allocated swap) and adjusts systemwide run queue size and swap queue size.

Once the clock interrupt handling is completed, the clock interrupt thread is context-switched off the processor, and the thread that was executing when the interrupt occurred resumes.

19.1.1. Thread Tick Processing

Tick processing is done for each kernel thread (if that thread is not an interrupt handler or an operating system kernel thread) running on a CPU. The kernel determines whether it is necessary to do tick processing for a thread by comparing the thread's t_lbolt with lbolt.

if ((!thread_away) && (lbolt - t->t_lbolt != 0)) {         t->t_lbolt = lbolt;         clock_tick(t); } 

The clock_tick() code is passed the kernel thread ID and invokes the scheduling-class-specific clock-tick function, that is, ts_tick() for timeshare and interactive class threads and rt_tick() for real-time class threads. These functions are discussed in "Real-Time Tick Processing." on page 229. Briefly, the functions determine if the thread has used up its time quantum, and they take the thread off the processor if it has. Back in the clock_tick() function, the following actions are performed:

• The user or system time values in the process and the LWP are incremented, depending on the mode the thread is in (system or user). Note that if a thread is executing in short bursts between clock samples, not all CPU time will be accounted for. User-based tools have been updated to avoid using these tick-based user or system times; instead they will now source microstate accounting data.

• The per-thread interval timers are tested (profiling and virtual timer, enabled with the setitimer(2) system call), and the appropriate signalSIGPROF or SIGVTALRMis sent if either timer has expired.

• The per-process CPU resource control limits are checked (maximum CPU seconds the process or project can consume).

• The process memory usage is updated in the uarea u_mem, which reflects the total address space size of the process.

The update completes the clock-tick processing for the thread.

19.1.2. DTrace Providers for Tick Processing

Some DTrace static probes are part of the sched provider.

# dtrace -l -n 'sched:::' |grep tick  2870      sched           genunix                        clock_tick tick 12666      sched                TS                           ts_tick schedctl-nopreempt 30273      sched                FX                           fx_tick schedctl-nopreempt 

The sched tick probe fires as a part of clock-tick-based accounting. In clock-tick-based accounting, CPU accounting is performed by examination of the threads and processes running when a fixed-interval interrupt fires. The lwpsinfo_t that corresponds to the thread that is being assigned CPU time is pointed to by args[0]. The psinfo_t that corresponds to the process that contains the thread is pointed to by args[1].

typedef struct psinfo {         int     pr_nlwp;            /* number of active lwps in the process */         pid_t   pr_pid;             /* unique process id */         pid_t   pr_ppid;            /* process id of parent */         pid_t   pr_pgid;            /* pid of process group leader */         pid_t   pr_sid;             /* session id */         uid_t   pr_uid;             /* real user id */         uid_t   pr_euid;            /* effective user id */         gid_t   pr_gid;             /* real group id */         gid_t   pr_egid;            /* effective group id */         uintptr_t pr_addr;          /* address of process */         dev_t   pr_ttydev;          /* controlling tty device (or PRNODEV) */         timestruc_t pr_start;       /* process start time, from the epoch */         char    pr_fname[PRFNSZ];   /* name of execed file */         char    pr_psargs[PRARGSZ]; /* initial characters of arg list */         int     pr_argc;            /* initial argument count */         uintptr_t pr_argv;          /* address of initial argument vector */         uintptr_t pr_envp;          /* address of initial environment vector */         char    pr_dmodel;          /* data model of the process */         taskid_t pr_taskid;         /* task id */         projid_t pr_projid;         /* project id */         poolid_t pr_poolid;         /* pool id */         zoneid_t pr_zoneid;         /* zone id */ } psinfo_t;