So here's the second part of my reply to Mr. Fuld's last response to me.
Considering how quickly this reply has grown, I may end up breaking it up into a third part as well.

On 8/15/2023 11:48 AM, Lewis Cole wrote:
>> On Tuesday, August 15, 2023 at 12:06:53AM UTC-7, Stephen Fuld wrote:
>> <snip>
>>>> And even since the beginning of time
>>>> (well ... since real live multi-tasking
>>>> OS appeared), it has been obvious that
>>>> processors tend to spend most of their
>>>> time in supervisor mode (OS) code
>>>> rather than in user (program) code.
>>>
>>> I don't want to get into an argument about caching with you, [...]
>>
>> I'm not sure what sort of argument you
>> think I'm trying get into WRT caching,
>> but I assume that we both are familiar
>> enough with it so that there's really
>> no argument to be had so your
>> comment makes no sense to me.
>>
>>> [...] but I am sure that the percentage of time spent in supervisor mode is very
>>> workload dependent.
>>
>> Agreed.
>> But to the extent that the results of
>> the SS keyin were ... useful .. in The
>> Good Old Days at Roseville, I recall
>> seeing something in excess of 80+
>> percent of the time was spent in the
>> Exec on regular basis.
>
> It took me a while to respond to this, as I had a memory, but had to
> find the manual to check. You might have had some non-released code
> running in Roseville, but the standard SS keyin doesn't show what
> percentage of time is spent in Exec. To me, and as supported by the
> evidence Scott gave, 80% seems way too high.

So let me get this straight: You don't believe the 80% figure I cite because it seems too high to you and it didn't come a "standard" SS keyin of the time.
Meanwhile, you believe the figure cited by Mr. Lurndal because it seems more believable even though it comes from a system that's almost certainly running a different workload than the one I'm referring to which was from decades ago.
Did I get this right?
Seriously?

What happened to the bit where *YOU* were saying about the amount of time spent in an OS was probably workload dependent?
And since when does the credibility of local code written in Roseville (by people who are likely responsible for the care and feeding of the Exec that the local code is being written for) some how become suspect just because said code didn't make it into a release ... whether it's output is consistent with what you believe or not?

FWIW, I stand by the statement about seeing CPU utilization in excess of 80+% on a regular basis because that is what I recall seeing.
You can choose to believe me or not.
(And I would like to point out that I don't appreciate being called a liar no matter how politely it is done.)

I cannot provide direct evidence to support my statement.
I don't have any console listings or demand terminal session listings where I entered an "@@cons ss", for example.
However, I can point to an old (~1981) video that clearly suggests that the 20% figure cited by Mr. Lurndal almost certainly doesn't apply to the Exec at least in some environments from way back when.
And I can wave my arms at why it is most certainly possible for a much higher figure to show up, at least theoretically, even today.

So the video I want to draw your attention to is entitled, "19th Annual Sperry Univac Spring Technical Symposium - 'Proposed Memory Management Techniques for Sperry Univac 1100 Series Systems'", and can be found here:

< https://digital.hagley.org/VID_1985261_B110_ID05?solr_nav%5Bid%5D=88d187d912cfce1a5ad1&solr_nav%5Bpage%5D=0&solr_nav%5Boffset%5D=2 >

Around timestamp [4:43] in the video, S.J. Trivedi, one of the gurus of the DA at the time, notes that *DA element of the Dynamic Allocator (DA) had been observed to take up 33% of the total CPU time for a 3x (pronounced "three by" for the unfamiliar Univac/Sperry Univac/Sperry notation who are still reading along) 1100/80A system with 3MW of memory.
He notes that "33%" usage effectively means that a customer who buys a 3x 1100/80A is buying a 2x 1100/80A to do useful work with the third CPU being used to take care of memory management.
He adds (presumably jokingly) that because the DA is non-reentrant, another CPU can't be added to help out the one doing the DA work, but if it had been re-entrant, then maybe one and a half CPUs (meaning 1.5 CPUs out of 3 CPUs or 50% of the available computing power in the system) to up to two CPUs (meaning 2 CPUs out 3 CPUs or 66% of the available computing power in the system) could be "gobbled up by the DA".
(FWIW, I *THINK* that the changes he was referring to became known as the "Performance Enhancement Package" (PEP) package which was integrated some time after I arrived at Roseville and I *HOPE* significantly reduced the average amount of time chewed up for memory management, but by how much, I have no idea.)

Now 33% isn't 80+% (nor is a hypothetical 50% or 66% for that matter), but it also isn't something that's around or under 20%.
And if you make the entirely reasonable assumption that there was/is more to the time spent in the Exec than just memory allocation, then may I not so humbly suggest that something north of 20% of total available CPU time might well be spent in the Exec.

Just for giggles, though, let's say that that was then and this is now, meaning that the amount of time spent in the Exec is (and has been for some time) roughly the same as the figure that Mr. Lurndal cited ... so what?
Mr. Lurndal apparently wants to argue that since the *AVERAGE* amount of time that some systems (presumably those whose OSs' names end in the letters "ix") spend in the supervisor is "only" 20%, that means that it isn't worth having a separate supervisor cache.
After all, his reasoning goes, if the entire time spent in the supervisor were eliminated, that would mean an increase of only 20% more time to user programs.

Just on principle, this is a silly thing to say.

It obviously incorrectly equates time with useful work and then compounds that by treating time spent in user code as important while time spent in supervisor mode as waste.
It shouldn't take much to realize that this is nonsense.
Imagine a user program making a request to the OS to send a message somewhere that can't be delivered for some reason (e.g. an error or some programmatic limits being exceeded), the OS should return a bit more quickly than if it could send the message.
So the user program should get a bit more time and the OS should get a bit less time.
But no one in their right mind should automatically presume the user program should be able to do something more "useful" with the extra time it has.
And even if the user program does come up with something "useful" to do, whatever it does, it isn't able to do what it originally wanted to do which was apparently worth doing or else it wouldn't have bothered at all.
Meanwhile, if the OS could send the message and could in fact could do so more quickly than usual, the time in the OS might well go down at least initially.
But that may be temporary as the time could go up because the user program tries to send even more messages resulting in more time being spent in the OS.
And note that time spent in the OS going up could mean that more "useful" work is getting done.

And if you need some evidence that small amounts of time spent in an OS can have a significant impact on what a user is able to accomplish that is disproportionate, I will point out that as a percentage, the amount of time spent in an interrupt handler is generally very small compared to the time spent in the rest of an OS.

But enough of principles, let's talk about the 20% figure Mr. Lurndal cites..

Unless the system is running only a single user program on a single CPU, this figure is almost certainly the *AVERAGE* amount of time that the supervisor flag is set for the user programs that just happen to be running on the system during some particular time (i.e. it's load dependent).
And being an *AVERAGE*, that means that even on the system that Mr. Lurndal was referencing, the amount of time sent in the supervisor versus the amount of time spent in user program(s) could well be much lower or higher for shorter periods of time which end up being averaged out in the wash.
So the amount of supervisor time that is in some sense "available" to improve (or decrease) system performance can well be more than the 20% average figure, even in this most simplistic analysis, especially if something out of the ordinary happens to happen.

So let's talk about the 20% figure and work loads just for giggles to see if something out of the ordinary can just happen to happen.

Once Upon a Time, electronic digital computers used to do a lot of number crunching.
Back in these Good Old Days, user program requests were presumably few and far between (since the programs called upon the supervisor for services pretty much without regard to what was happening in the outside world).
And when a user program was in control, it had "useful work" to do.
Over time, such programs started running parts in parallel on different CPUs and Amdahl wrote his famous paper about how speed up of the small, non-parallel part of the programs didn't do much to increase overall performance of the parallel portion.
Back then, though, performance was measured in terms of CPU utilization and throughput and maybe turn around time.
This sort of computing environment is still in existence today, and as best as I can tell, it is the sort of environment that Mr. Lurndal works in and so is familiar with.

But that stopped being the only (and I suspect the dominant) computing environment more than 50 years ago as programs started to talk to users interactively.
Once that started to happen, performance stopped being measured simply by CPU utilization and throughput, but instead by response time and what Tannenbaum calls "proportionality" (which is to say, how much the actual response seen by a user matches the user's expectation for what performance should be) ... which is something I tried to point out to you in an earlier post.
Lo and behold, contention for access to resources became more of a problem, and with it, the use of queues to manage these resources.
And with queues, queuing theory became something to take note of.
Two things in particular to take note of are (1) the average time between the arrival of requests for something and (2) the average amount of time that it takes to process a request.
If the average time to process a request is less than (i.e. shorter than) the average time between the arrival of requests, then queue generally either don't form at all or don't get very long.

But the average time between arrivals is the *AVERAGE* time, not a guaranteed maximum time between arrives.
And so if it just so happens that a burst of arrivals occurs in less than the average, queues can form and lengthen, with the result being that until the arrival times and queues return to normal, all bets are off when it comes to response times AKA the latency of the requests.
CPU utilization can grow up to 100% even today if you just happen to be unlucky.
(OBTW, remember when I pointed out what S.J. said about the DA being queue driven?)
Other than just waiting for things to work themselves out on their own, about the best you can do to get things back to normal is to throw more resources at the problem.
For example, if additional processor time can help (by reducing the average response time), then throwing more processors at the problem can potentially be useful ... like adding more cashiers to the check out lines of a store with the lines start getting long.

Now as it turns out, this tendency for response time (AKA the latency) going to hell every so often is a *VERY BIG DEAL* .
In fact, it's a *HUGE DEAL* when it happens because the effects can propagate all over the place when we're talking about things that are hooked up in a network as is common these days.
The effects of this so-called "tail latency" can cost someone massive amounts of money that is not being made.
Now often times, network components are the focus of the show, but since response time problems can propagate, real live computers and their OSs are also in the picture.
You can verify this for yourself by a little Googling with "tail latency" along with whatever other search terms you'd like to toss in.

Now at this point, you may be tempted to say something like, "yes, well, that's all well and good, but it's a lot of arm waving compared to the nice solid 20% figure that Mr. Lurndal cited.".
If something like that does cross your mind, I would like to point out that I have no burden of proof to show anything here.
I SUSPECT that a separate supervisor cache could help boost system performance, but I don't know if that's actually the case.
That's why I asked questions to try to find out if my suspicions were correct.
It was Mr. Lurndal who came out and made the statement that he didn't think that a separate supervisor cache would help because in his experience, only 20% of the available time is spent in supervisor code.
So it's Mr. Lurndal's logical responsibility to provide arguments and evidence to support his statements about there being no useful benefit to having a separate supervisor cache -- not mine -- and he simply hasn't done so.
He has waved his arms at 20% (or even 10%) time spent in the supervisor for some systems he is familiar with, which as my arm waving hopefully showed is just so much bullshit as it doesn't tell you anything about benefit.
And the only "evidence" he's provided is smoke intended to show that he's an "expert" on cache hardware (in particular ARM cache hardware).
I'm more than willing to concede he's a cache "expert", but unfortunately for him that doesn't say a damn thing about the correctness/truthfulness of his statement.
20% is still just 20% which (in this case) is just useless figure.
Even though I didn't need to provide any response, what I've presented here is evidence that his so-called evidence isn't as compelling as he makes it out to be.

So If you want to believe that Mr. Lurndal's 20% figure is somehow "meaningful" about anything (at least enough so that you're willing to call me a liar), then that's your call.
But please don't pretend that the 20% figure is anything but at best, a single data point with all that entails in terms of being a slam dunk "proof" of what he's claiming.

So I'm going to end this part and go on to a new Part 3.