Author Topic: FF 45.x and VIRTUALADDRESSLIMIT setting...  (Read 1847 times)

Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 14
  • -Receive: 17
  • Posts: 783
  • Karma: +0/-0
    • View Profile
FF 45.x and VIRTUALADDRESSLIMIT setting...
« on: February 08, 2020, 06:40:38 pm »
Hi Everyone,

Not sure if this is just something weird on my machine, or whether others have seen this as well, either way, the results I am seeing are actually pretty positive, so I wanted to share my observations.

Alright, so I've been running FF45.x for a while now, currently an AMD Phenom II X6 specific build that Dave was kind enough to supply a while back. In general, no complaints, it works.

Now, recently as I was playing around with a test release of ACPI driver from AN I was trying to see if the changes allow me to finally boot OS/2 in the full 6-core CPU config. Right now I'm running with 5 cores only, turning on the 6th always causes the dreaded WPS blue-screen hang. I adjusted the VIRTUALADDRESSLIMIT setting from 2560 to 3072 to see if that had any impact.

OK, so the ACPI changes did not net an improvement here, but I left the VIRTUALADDRESSLIMIT set at 3072.

Low and behold, all of a sudden the dreaded FF CPU spike (on certain sites/applications: GMAIL, some of my automotive forums, etc.) literally nearly went away when the particular browser tab no longer has the focus.

This was never the case in the past. The CPU spikes would continue unless/until I literally opened a blank TAB and left the FF focus on that blank tab.

Take a look at the attached CPU monitor screenshot, where the early part is the new behaviour, while the later part is the behaviour as it used to be.

Strangely this all seems to be the result of just the VIRTUALADDRESSLIMIT change. Anyways, my machine has been up for the past 7 days, same FF start, so no FF re-start which is literally a good amount of browsing with much improved stability.

I've got some changes coming up that will require a re-boot, so I'm curious if this behaviour is a result of just some weird runtime interaction, or whether it is consistent. Will find out later on today...

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 192
  • Posts: 2659
  • Karma: +6/-0
    • View Profile
Re: FF 45.x and VIRTUALADDRESSLIMIT setting...
« Reply #1 on: February 09, 2020, 04:24:54 am »
Seems strange that increasing the virtualaddresslimit would fix your CPU spiking, unless it was unreasonably low to begin with.
Actually your CPU spiking seems weird. Here if I go to gmail, once it loads, the CPU stabilizes with one core reading 1%, at that usually the browser, SM in my case but most of the code is shared, sits at about 1%. Does get spiky when writing this, scrolling the Gmail page and such. Also some GIFs cause spiky behaviour.
At one point I did do something to my profile that caused continuous spiky behaviour, never did figure it out and eventually fixed it by reverting to a week old backup.
I'd suggest creating a new profile and logging into Gmail and see if you still get the spikes. Same with your automotive forums, though they might have GIFs that trigger the behaviour. Even this page, if I enable the JavaScript so it displays the icons at the top, gets spiky, I assume due to GIFs.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 14
  • -Receive: 17
  • Posts: 783
  • Karma: +0/-0
    • View Profile
Re: FF 45.x and VIRTUALADDRESSLIMIT setting...
« Reply #2 on: February 09, 2020, 06:15:47 am »
Hey Dave,

Yup, it was weird, almost too weird to be true...LOL, indeed, following a re-boot my old CPU spike behaviour is back.

Well, enough excitement for one day I suppose.

I am not sure why I'm seeing this, I've played around with the various frame-refresh settings in the past, and yeah, most of the pages that do cause the heavy CPU loading are the ones with a pile of GIFs in there.

Not sure what is causing that on gmail though, especially since I'm using the HTML version given how unbareable the standard gmail browser page is (performance wise here anyways).

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 192
  • Posts: 2659
  • Karma: +6/-0
    • View Profile
Re: FF 45.x and VIRTUALADDRESSLIMIT setting...
« Reply #3 on: February 09, 2020, 07:18:03 am »
Yea, there's something wrong with our GIF decoder but at least the CPU spikes go away when changing to a different tab.
As for Gmail, I think I'm using the basic HTML as well though it is hard to tell.There is also a bunch of settings that might change behaviour that I haven't touched but perhaps you have.
I usually just download my Gmail mail to Thunderbird and likewise write and send it from Thunderbird so seldom open the web interface, much simpler then using the web interface.
You should still do a test with a new profile for comparison.

Sergey Posokhov

  • Full Member
  • ***
  • Thank You
  • -Given: 2
  • -Receive: 6
  • Posts: 136
  • Karma: +0/-0
    • View Profile
    • OS/2 API Research
Re: FF 45.x and VIRTUALADDRESSLIMIT setting...
« Reply #4 on: February 12, 2020, 09:58:19 pm »
It seems to be a Heap Compression...

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 11
  • -Receive: 192
  • Posts: 2659
  • Karma: +6/-0
    • View Profile
Re: FF 45.x and VIRTUALADDRESSLIMIT setting...
« Reply #5 on: February 12, 2020, 11:46:14 pm »
It seems to be a Heap Compression...

Yes, it could be garbage collection. about:memory allows running the garbage collector.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Thank You
  • -Given: 14
  • -Receive: 17
  • Posts: 783
  • Karma: +0/-0
    • View Profile
Re: FF 45.x and VIRTUALADDRESSLIMIT setting...
« Reply #6 on: February 24, 2020, 06:59:15 pm »
Well, it turned out to have been a very specific anomaly...no explanation how I got there, but yeah, non-repeatable.

Lars

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 64
  • Posts: 623
  • Karma: +0/-0
    • View Profile
Re: FF 45.x and VIRTUALADDRESSLIMIT setting...
« Reply #7 on: February 25, 2020, 10:02:11 am »
Have you ever tried to reduce your number of cores to one core per package/unit ? The BIOS should allow this and I would expect that fixes your stability problems. That will leave you with 3 cores which is no loss, really. At least the Bulldozer architecture is offering miserable performance gain from the "hyperthreading" (AMD names this differently but it is the same thing). There are just too many HW components being shared amongst two cores of a common package/unit or whatever they call it.

Olafur Gunnlaugsson

  • Full Member
  • ***
  • Thank You
  • -Given: 36
  • -Receive: 18
  • Posts: 198
  • Karma: +0/-0
    • View Profile
Re: FF 45.x and VIRTUALADDRESSLIMIT setting...
« Reply #8 on: February 25, 2020, 01:32:17 pm »
Have you ever tried to reduce your number of cores to one core per package/unit ? The BIOS should allow this and I would expect that fixes your stability problems. That will leave you with 3 cores which is no loss, really. At least the Bulldozer architecture is offering miserable performance gain from the "hyperthreading" (AMD names this differently but it is the same thing). There are just too many HW components being shared amongst two cores of a common package/unit or whatever they call it.

He uses a Phenom II X6 with 6 full Int/FPU cores, no hyperthreading in sight. PII X6 is not a Bulldozer but a K10 architecture, and Ryzen has hyperthreading while Bulldozer has not but rather CMT (Clustered Multi Threading) where the secondary core does not have a FPU unit so some tasks are not assigned to the secondary core, but it is still a full core rather than the fake core hyperthreading offers, e.g. a 6x Bulldozer core has 6 integer units but only 3 floating point ones. That people believe that CMT is the same as Hyperthreading just tells you how insanely good the Intel marketing division is.
« Last Edit: February 25, 2020, 01:33:53 pm by Olafur Gunnlaugsson »

Lars

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 64
  • Posts: 623
  • Karma: +0/-0
    • View Profile
Re: FF 45.x and VIRTUALADDRESSLIMIT setting...
« Reply #9 on: February 25, 2020, 07:45:49 pm »
I only remember that I read on some gamers forum that Bulldozer even performs slightly better with only one core per unit active. In practice I can say that using 4 cores instead of 8 on my Bulldozer type of CPU makes close to no difference (Windows is busy rotating the hard disk and OS/2 is busy on choking and scheduling on that many cores).
That tells you how insanely good the AMD marketing is.

Lars

  • Hero Member
  • *****
  • Thank You
  • -Given: 0
  • -Receive: 64
  • Posts: 623
  • Karma: +0/-0
    • View Profile
« Last Edit: February 25, 2020, 07:57:01 pm by Lars »

Olafur Gunnlaugsson

  • Full Member
  • ***
  • Thank You
  • -Given: 36
  • -Receive: 18
  • Posts: 198
  • Karma: +0/-0
    • View Profile
Re: FF 45.x and VIRTUALADDRESSLIMIT setting...
« Reply #11 on: February 25, 2020, 09:16:53 pm »
I only remember that I read on some gamers forum that Bulldozer even performs slightly better with only one core per unit active. In practice I can say that using 4 cores instead of 8 on my Bulldozer type of CPU makes close to no difference (Windows is busy rotating the hard disk and OS/2 is busy on choking and scheduling on that many cores).
That tells you how insanely good the AMD marketing is.

I cannot speak for your setup, but on mine performance degrades on both eCS and windows if I disable the secondary cores this is especially noticeable in Win10-64, and on well multithreaded tasks such as as OCR the difference is striking, over 40%. And citing games benchmarks that do limited multithreading, and no application to OS/2 is odd.

My point still stands, AMD cores do real work, Hypercores do not, and in fact they mess timing up if you use any sort of application or drivers that require RT response.

The second point is that people on here are advising someone that has a computer that has neither Hyperthreading nor CMT, to adjust his CMT settings in response to a problem. If you lot fail to see the stupidity there, then there is little hope of seeing it elsewhere ...