linuxmemes

Well behaving programs give control back to the kernel as soon as they are done with what they are doing. If they don't the control is forcefully taken away after some assigned time.

It looks something like this:

Something happens – e.g. a key is pressed – a process waiting for this event is woken up and gets e.g. 100ms to do it stuff. If it can handle the key press in 50ms, kernel notes it used 50 ms of CPU time and can give control to another process waiting for an event or busy with other work. If the key press triggered long computation the process won't be done in 100ms, the kernel notes it used 100ms of CPU time and gives control to other processes with pending events or busy with other work.
After one second the kernel may have noted:

Process A: used 50ms, then nothing, then 100ms, another 100ms and another 100ms
Process B: was constantly busy doing something, so it got allocated 6 * 100ms in that one second
Process C: just got one event and handled it in 50ms
Process D: was not waken at all

So total of 1000ms was used – the CPU was 100% busy
Of that 60% was process B, 35% process A and 5% process C.

And then that information is read from the kernel by top and displayed.

How does the OS even yank the CPU away from the currently running process?

Interrupts. CPU has means triggering and interrupt at a specific time. Interrupt means that CPU stops what it is doing and runs selected piece of kernel code. This piece of kernel code can save the current state of user process execution and do something else or restore saved execution of another process.

Timer based interrupts are the foundation of pre-emptive multitasking operating systems.

You set up a timer to run every N milliseconds and generate an interrupt. The interrupt handler, the scheduler, decides what process will run during the next time slice (the time between these interrupts), and handles the task of saving the current process' state and restoring the next process' state.

To do that it saves all the CPU registers (incl stack pointer, instruction pointer, etc), updates the state of the process (runnable, running, blocked), and restores the registers for the next process, changes it's state to running, then exits and the CPU resumes where the next process left off last time it was in a running state.

While it does that switcheroo, it can add how long the previous process was running.

The other thing that can cause a process to change state is when it asks for a resource that will take a while to access. Like waiting for keyboard input. Or reading from the disk. Or waiting for a tcp connection. Long and short of it is the kernel puts the process in a blocked state and waits for the appropriate I/O interrupt to put the process in a runnable state.

Or something along those lines. It's been ages since I took an OS class and maybe I don't have the details perfect but hopefully that gives you the gist of it.

cpu.land

yes, it looks at a fine-grained clock, usually a cycle counter provided by the CPU for this purpose, to aggregate total on-cpu time for each process.

Look up preemptive task scheduling. Basic processes will get interrupted after using a too long time slice.

How do you measure how much memory a process is using?

Shared libraries. Shared memory. Virtual. Physical. Memory mapped files. Some applications depend heavily on the availability of the file system cache for good performance, so should you consider that memory technically in use by that process? What if a process is providing a service to other applications and allocates memory on behalf of those apps to provide those services? If I ask the kernel to allocate lots of things for me to do my job should that really be my memory?

There are popular measures to get an idea of the memory consumed by a process, but none can tell the whole truth and nothing but.

I.e. could be the dress.

Literally

"sudo kill -9 4346" for additional brutality

100% equals one full core. Higher numbers are possible for multithreaded processes.

Brother, let me show you this: https://i.imgur.com/PbU8U5n.png