Page 3 of 3
Re: What makes your OS special?
Posted: Mon Jan 20, 2020 12:45 am
by 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.
Re: What makes your OS special?
Posted: Mon Jan 20, 2020 2:42 am
by 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...
Re: What makes your OS special?
Posted: Mon Jan 20, 2020 11:35 am
by 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.
Re: What makes your OS special?
Posted: Mon Jan 20, 2020 1:37 pm
by 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...
Re: What makes your OS special?
Posted: Mon Jan 20, 2020 2:37 pm
by bzt
Qbyte wrote: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
Re: What makes your OS special?
Posted: Mon Jan 20, 2020 10:00 pm
by 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
Re: What makes your OS special?
Posted: Thu Jan 23, 2020 5:26 pm
by nyc
eekee wrote: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.