![]() Of course the network is just one example, there are many other ways for the kernel to do things that can't be traced directly to one process. For example, if there's a process that sends packets to another machine and causes this other machine to reply, but the firewall blocks the reply packets, then the time spent parsing and discarding the reply packets won't be traced back to that sending process but if the sending process stops, which causes the remote machine to stop replying, then the kernel won't spend time rejecting the packets any more. Yet sometimes that CPU time is indirectly caused by some process. So it's possible to have CPU time that doesn't belong to any process. If a process ends up receiving that packet, some of the reception time will be put on that process's tab, but not the early stages. The packet may be rejected via a firewall rule, in which case no process can claim that processing time. The kernel executes code to read and parse the network packet so far no process is involved. For example, suppose that an interrupt is triggered by the network card. In particular, hardware interrupts don't intrinsically belong to a particular process. Some of the things that the kernel does can't be directly accounted against one process. ![]() ![]() Kernel time is the “system time” reported by the time utility. Kernel code is normally attached to a process: if the kernel is executing a system call, then the in-kernel processing is accounted as belonging to that process. User land code is always attached to a process, so if the CPU is busy executing user land code, it shows on some line in top. The code executed on a unix system is classified as either kernel code or user land code.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |