OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 8:19 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: What makes your OS special?
PostPosted: Mon Jan 20, 2020 12:45 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
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.


Top
 Profile  
 
 Post subject: Re: What makes your OS special?
PostPosted: Mon Jan 20, 2020 2:42 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7612
Location: Germany
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...

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re: What makes your OS special?
PostPosted: Mon Jan 20, 2020 11:35 am 
Offline
Member
Member

Joined: Tue Jan 02, 2018 12:53 am
Posts: 51
Location: Australia
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.


Top
 Profile  
 
 Post subject: Re: What makes your OS special?
PostPosted: Mon Jan 20, 2020 1:37 pm 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7612
Location: Germany
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...

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re: What makes your OS special?
PostPosted: Mon Jan 20, 2020 2:37 pm 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
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:
Quote:
FreeBSD also runs fewer processes [than Debian Linux]

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: What makes your OS special?
PostPosted: Mon Jan 20, 2020 10:00 pm 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 812
Location: Hyperspace
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. :P 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:
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

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
 Post subject: Re: What makes your OS special?
PostPosted: Thu Jan 23, 2020 5:26 pm 
Offline
User avatar

Joined: Sun Dec 29, 2019 10:59 pm
Posts: 17
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. :P 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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 30 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group