MP 7,1 No AppleID will be entered and the request will be skipped during initial MP7,1 setup

[bxs]

Subject: No AppleID will be entered and the request will be skipped during initial MP7,1 setup.

In order to reduce the number of system and unnecessary processes I will not enable Apple ID when requested during the initial setup, nor will I accept sending analytics to Apple nor other such things.

Also, applications such as Mail, Photos, GarageBand, Pages, News, AppleTV, Podcasts, Music and Find My will never be launched and will be removed from the Dock. These type applications will be used on a personal MBP laptop.

Safari will likely be an exception as that will be needed to check in with our 3rd party applications vendors.

The primary reason for doing this is to try to minimize the number of processes that the typical macOS launches. I just now checked on my MBP and there are some 520 processes floating about, and most of them appear to be sleeping.

It will be of interest to observe if the above setup technique will lesson the number of processes that we have no interest in for being on the MP7,1. I have to believe having AppleID setup would cause a lot of extra processes to be in operations that we have no interest in and will just get in our way (hinder our workflows) for doing our real work.

 

[goMac]

It will be of interest to observe if the above setup technique will lesson the number of processes that we have no interest in for being on the MP7,1. I have to believe having AppleID setup would cause a lot of extra processes to be in operations that we have no interest in and will just get in our way (hinder our workflows) for doing our real work.

AppleID will knock out a few trivial ones. Aside from that, nothing else is in that list is likely to reduce background processes.

520 is a pretty normal amount of processes for a modern system. Most tasks the system does have been split up into multiple processes for security and modularity. I would bet a large majority of those are core OS processes and don't have anything to do with installed apps.

Sleeping processes should also have absolutely no effect on performance. They aren't scheduled to do any work.

 

[th0masp]

You should probably also go through launchctl and disable/remove any unwanted daemons installed by your applications (VOXagent recently drove me crazy....) and setup an inward looking firewall like Littlesnitch (there's a fairly new freeware alternative but I can't recall the name offhand) to block unwanted outgoing connections and identify processes that are basically just there to talk to some server on the web.

There's a lot of background noise going on in a macOS install that does not benefit the user. Some of this stuff is spamming the logfiles, making them unreadable until you clean up.

 

[sprague.rod]

I don’t believe what you are doing will make much difference. Still I’d love to know if it does.

 

[ASenseOfLambert]

What kind of experiment is that?

 

[fuchsdh]

I also cannot fathom what the actual end result you’re hoping for is. A .5% speed increase?

 

[ZombiePhysicist]

It's a great experiment. If only to confirm the suspicion that it makes little to no difference performance wise.

 

[bxs]

This approach will be my first attempt to reduce the amount of 'OS chatter'.

I will be running a long running multi-threaded code across some 14 cores (28 threads) of a 16-core MP7,1. I'd love to be able to lock these 28 threads for the exclusive use for my code, leaving the remaining cores for the system to do its 'chattering'.

I will be exploring the use of the system call mlock() for locking my code into RAM (memory) so that it cannot be subject to involuntary paging out. Reducing the system 'chatter' should help this memory-locking to be achieved without causing issues, such as 'deadlock' situations.

Memory-locking is a technique used by realtime applications, for obvious reasons.

...and of course the macOS kernel software employs memory locking as can be seen in Activity Monitor's "Memory" tab - "Wired Memory".

 

[goMac]

This approach will be my first attempt to reduce the amount of 'OS chatter'.

Process chatter isn't really a thing. A process existing doesn't mean it's chattering.

Modern UNIX is built to handle tens of thousands of processes. 500 is really nothing.

Most the processes in macOS are just things that used to exist under a single process, but were split for security reasons. Safari (or any modern browser) is a basic example. Each window/tab is a different process to keep pages from reading each other's data, but the same design is present throughout the system. Process count is a completely useless metric by itself.

I will be exploring the use of the system call mlock() for locking my code into RAM (memory) so that it cannot be subject to involuntary paging out. Reducing the system 'chatter' should help this memory-locking to be achieved without causing issues, such as 'deadlock' situations.

"Chatter" won't have the effect on mlock that you think it will. Process count is a completely irrelevant metric for this sort of performance. CPU usage is the more relevant metric. Sleeping processes don't "chatter."

Memory-locking is a technique used by realtime applications, for obvious reasons.

macOS isn't a real time system, no matter how many processes you kill. Neither is Windows or Linux. And there is a reason for that...

 

[bxs]

A process that is active has the potential to 'chatter'. All it has to do, is to request attention for the CPU via a system call. When the system schedules it to the CPU and existing CPU execution thread has to be exchanged out to make room for the new execution thread. CPU exchanges are hugely expensive as the current execution thread's state has to be saved so it can be safely resumed at a later point. The hundreds of processes that exist all have the potential to cause this type of 'chatter' and can slow down the 'real' user workload. The intent for reducing system 'chatter' is to give the real user workload the best chance of executing without being stalled but the many system processes that are not required for getting the user's workload completed. Finding the processes that are in no way helping the user's workload to complete is a challenge for sure.

Safari is a good example of a collection of processes that get spawned off that do not help a user's real workload to complete. For me, Safari would not be launched for this reason.

In general, no process is exempt from being paged out of main memory (RAM), with the exception of the kernel's wired memory. The kernel locks a portion of its memory to avoid it from being paged out for good reasons; that is, to give the best response to processes needing system resources in a timely (or time-critical) manner.

Memory locking is provided in macOS. The amount of memory that a process can lock is limited by the environment value RLIMIT_MEMLOCK - see 'man mlock'.

Let me be clear - I'm not claiming macOS is a real-time system. I simply mentioned real-time as an example where memory-locking is needed; that is, to get work done quickly without time being wasted.

My intention is to do what I can to get my work done quickly. To this end I will attempt to configure my system to reduce unwanted processes that cause unnecessary system 'chatter'. For example I don't want Photos helper processes continually polling the CPU in order to collect face information found in photo images - so will not have Photos active on my system. The same is true for not wanting Mail, Messages, News, Calendar, Spotlight, istat, iCloud Drive, and so on.

 

[konqerror]

My intention is to do what I can to get my work done quickly.

Sounds like a classic case of premature optimization... you spend hours re-configuring the system to save minutes of computation time. Worse, you trigger weird system behavior like crashes and runaway processes that take you hours to debug.

Besides, the whole problem is flawed from the very start. Run a server Linux distro or Windows Server, where the OS vendor has created and validated lightweight configurations.

 

[goMac]

A process that is active has the potential to 'chatter'. All it has to do, is to request attention for the CPU via a system call. When the system schedules it to the CPU and existing CPU execution thread has to be exchanged out to make room for the new execution thread. CPU exchanges are hugely expensive as the current execution thread's state has to be saved so it can be safely resumed at a later point. The hundreds of processes that exist all have the potential to cause this type of 'chatter' and can slow down the 'real' user workload. The intent for reducing system 'chatter' is to give the real user workload the best chance of executing without being stalled but the many system processes that are not required for getting the user's workload completed. Finding the processes that are in no way helping the user's workload to complete is a challenge for sure.

...

macOS is not a real time operating system. That's usually considered a good thing because it has real multitasking, and better security.

I say that because it sounds like what you really want is a real time system. macOS is not a real time system and any attempt to make it act like one is doomed to failure. The kernel and scheduling do not act like you think it does, and simply clearing other processes out of the way does not at all guarantee that your preferred process will get more time.

Let me be clear - I'm not claiming macOS is a real-time system. I simply mentioned real-time as an example where memory-locking is needed; that is, to get work done quickly without time being wasted.

But that's exactly what you want. You're trying to get the kernel scheduler to give you exclusive access to resources. Which again, is doomed to failure. You're swatting a few ants while sitting in an ant hill. This isn't DOS.

Any app you run in macOS needs to talk with background processes to do it's job. Touching the window server... Metal... these are all background processes. You're going to have context changes on CPUs. Period.

Knocking out really minor tasks is ignoring the major ones you will hit that cause context switches.

 

[bxs]

By not running the Apple bundled applications should not and will not trigger weird system behavior; better still, by not running them their bugs will be avoided altogether.

Not setting up AppleID and not running Apple's bundled applications takes very little time and is done easily.

When one has a complex engineering problem to solve that can take weeks to solve, then improving a single digit percentage of performance can result in solving the problem in less days or for allowing more iterations to be performed to refine a solution.

I'm not talking about making 'major surgery' to the Mac. I'm making careful and small easy done changes that I believe will be beneficial for my work.

 

[Z28McCrory]

I’ve been noticing a lot of your posts lately in anticipation of your new computer shipping, and I think you’ll be much less bored once you actually have your 7,1 in your hands.

 

[bxs]

I’ve been noticing a lot of your posts lately in anticipation of your new computer shipping, and I think you’ll be much less bored once you actually have your 7,1 in your hands.

I understand your thinking, but it's not boredom at all; rather it's me doing due diligence and assembling my options, and to be ready at the starting line, so to speak.

Much of my activity on this forum is to satisfy myself I've made the right choice for our MP7,1 configuration. I have some 2 weeks left for our current MP7,1 order staying in its "Processing" phase allowing me to cancel the order or canceling and re-ordering a different MP7,1 configuration. If I discover some reason(s) for canceling our order based on what I read in this forum it makes sense for me to be engaged in reviewing and responding to all the MP7,1 postings here.

There's obviously a wealth of information in this forum and I'm simply taking advantage of it, and posting my questions to get helpful feedback.