What makes your OS special?

[iansjack]

I guess you could always limit the number of runnable processes to the number of free cores, but that would be a silly restriction. I'm guessing that most of us are targeting processors with less than 32 free cores.

[Solar]

Can it be that you are severely underestimating the number of processes running on your average machine? I did a quick head count on the machines I have access to and came up with...

• 101 processes on an idle Raspberry Pi;
• 195 on a Synology DiskStation;
• 216 on an idle Linux desktop;
• well over 500 on a Linux server.

Granted, a lot of those are background processes, daemons etc., but those need to run as well...

[Qbyte]

I think that's a testament to how ludicrously over-engineered commercial systems are, as you could probably terminate a good 90% of those processes without noticing a damn difference. Nevertheless, a many-core system could handle that scenario by having a small number of cores with a simple fair scheduling policy and allocating daemons and other background tasks to them. That way, the majority of cores could still be hard real time for user applications. This could also be done adaptively so as to not waste cores. All cores could start as fair, but each time the user starts a new application, it would be allocated it's own core and the policy for that core would then swap to hard real time, and any background tasks on that core could be migrated to a different one so that they never suffer from starvation.

[Solar]

Which one would you want to terminate? thermald? acpid? dbus? wpa_supplicant? udisksd? lightdm? sshd? XOrg? dhcclient? systemd? gnome-keyring-daemon? mate-session? ssh-agent? dconf-service? pulseaudio? clock-applet? volume-control-applet? The 7 processes alone involved in running this firefox session I am typing in? The shell I am looking at for the list of processes? The game running its course in the background, or any of the processes involved in recording that game?

And that's just the high-profile ones.

"Running processes" isn't just the applications you are using directly. That might have been the case in the 80's, but even my 90's Amiga rig ran about 50 processes at any one time...

[bzt]

I think that's a testament to how ludicrously over-engineered commercial systems are, as you could probably terminate a good 90% of those processes without noticing a damn difference.

True. I think over-complicated mainstream OSes is one of the reasons why this community exists

FYI, distrowatch switched from Linux to FreeBSD. One of their reasons was:

FreeBSD also runs fewer processes [than Debian Linux]

Cheers,
bzt

[eekee]

I remember when Linux had very few processes. There were no kprocs & no udev, but there was also no acpi, wpa, thermal monitoring, automounting... It was refreshing. It was also very capable, having already powered the rise of the Internet. I'm sure it was less complicated than several active projects on our list right now (but I don't really want to check).

What really surprised me was how many procs Plan 9 uses. The list is surprisingly long on a freshly installed system. It gets worse with a bit of use:

Code: Select all

term% uptime
pargas up 31 days, 08:57:53
term% ps | wc -l
    149
	total (no header)
term% ps | grep cwfs64x | wc -l
     23
	disk filesystem
term% ps | grep rio | wc -l
     12
	2x window system
term% ps | grep clock | wc -l
      6
	2x very simple program
term% ps | grep acme | wc -l
      7
	1 text editor displaying 2 files

[nyc]

I remember when Linux had very few processes. There were no kprocs & no udev, but there was also no acpi, wpa, thermal monitoring, automounting... It was refreshing. It was also very capable, having already powered the rise of the Internet. I'm sure it was less complicated than several active projects on our list right now (but I don't really want to check).

I'm not sure how significant the number of kernel threads is. A number of them are probably not worth representing in ways visible to userspace unless they can be manipulated as tasks, but apart from a relatively purist concern about namespace pollution, are harmless. The real concerns are per-thing overheads and asymptotic complexities for things such as threads, processes, file handles, memory mappings, etc. Easy exercise: a forking server (here the use of fork() isn't really significant, but rather the fact a new process is spawned for each connection) with a large shared memory segment. Things like to use SHM_HUGETLB on Linux to trim down the pagetable space overhead by a constant factor, but it's still quadratic: linear in the number of processes times linear in the size of the shared memory segment, K*p*v. This is a very significant real-world example. Shared pagetables (mind you, all the way up the radix tree hierarchy) would render the overhead of a forking server merely linear in the virtualspace for mapping shared memory plus linear in the number of processes. (I suspect out-of-tree patches for Linux to do so might still be around.) There are also concerns about the pinned memory usage, say, per-thread and perhaps per-process. Discarding reconstructible pagetables and potentially swapping pagetables that aren't reconstructible from e.g. file offset calculations can render potentially very large kernel data structures un-pinned. For threads, M:N threading in combination with asynchronous system calls can cut down the space overhead for running threads' kernel stacks to one per CPU in tandem with smaller queued callbacks per blocked user thread for potentially very significant constant factor reductions in pinned memory per thread.

Compared to such concerns, user-visible kernel-spawned kernel threads that are only O(nr_cpus) in number are IMNSHO negligible. Not to say I'm not one of the purists who disapproves of the pid namespace pollution.