TThrottle and extensive pagefaulting

[Pepo]

Changed: Drastically reduced TThrottle overhead, on some systems with NVIDIA cards and WIN 7.

In what ways actually? (I had to nitpick, sorry.)

Probably it does not concern my Win 7 notebook with nVidia G105M. I've made some screenshots of Process Explorer's properties window of TTh 1.90 after running 2 weeks (occasionally slightly throttling apps to some 5-15%), then installed a newer 2.10.1 and checked its consumption after 2 days:

• Kernel time usage 2:30 hours (spread nearly evenly to 2 threads), in line with 18 hours after 2 weeks,
• 26 000 000 000 000 CPU cycles, in line with 199 000 000 000 000 CPU cycles after 2 weeks, approximates to 0.15GHz? Seems fine to me, some 1-2% of a 4 core 1.8GHz CPU?
• Number of page faults just overflowed 31 bits a hour ago and continues,
• I/O Other is 3 434 000, is much less than 137 068 000 after 2 weeks, no idea whether this matters?
• I/O Bytes History graph shows steady 6 KB/s, my previous screenshots were showing 1/5th of this, again no idea whether this matters?

(I've still to check my old WinXP machine with Duron and ATI dinosaurs, and one more older dual-core + nVidia notebook.)

(Fred, enjoy your bike trip!)

[fred]

In what ways actually? (I had to nitpick, sorry.)

(Fred, enjoy your bike trip!)

This only affects some cards on some OS. For some reason the driver interface consumed a lot of CPU time. Probably Win 7 with high end (multiple) Graphic cards.
Others OS or cards may not notice anything at all.

I'm hiking, almost the same but no wheels.

[Pepo]

(Fred, enjoy your bike trip!)

I'm hiking, almost the same but no wheels.

I've probably misread the first character
anyway...

[Pepo]

Finally I could return to my "loving" thread with some new relevant information, which I found interesting (albeit posibly not useful ).

While checking the intensively-pagefaulting new SETI v7 app, I've noticed that the the Process Hacker has a tool named WS Watch, which is able to "monitor page faults that occur in a process" and break the PFs and list their counts according to functions, where they happen. It helped there to confirm, that the PFs are indeed happening in the used FFTW library during frequent (de)allocations of memory (no idea using which allocation function), which I believe causes the memory area always being get off the process' working set (to the Standby List?), and taking it back to process' working set has always to cause some (at least soft) page faults.

So I've got the idea to check the TTh's pagefaults too. Tested with 3.51, started some 2 weeks ago, the monitoring window was opened some 2 days ago and counted Page Faults for some 500 function calls, of which probably the following ones are somehow relevant (or I've considered them being of some interest ):

8 241 420, ~ ntoskrnl.exe!TmCurrentTransaction+0x159
1 723 150, + ntoskrnl.exe!ExGetPreviousMode+0x216
1 478 681, + win32k.sys!EngFntCacheLookUp+0x8e90
1 438 266, ~ kernel32.dll!Thread32Next+0x79
1 434 827, ~ kernel32.dll!Thread32Next+0x9a
  799 873, ~ kernel32.dll!Process32NextW+0x7c
  797 855, ~ kernel32.dll!Process32NextW+0xa0
  721 538, + DpFbview.dll!Ordinal9+0xc9743
  477 129, ~ ntdll.dll!RtlMoveMemory+0x250
  218 769, + win32k.sys!memset+0x80
  130 060, ~ kernel32.dll!CreateToolhelp32Snapshot+0x279
             (other 14 calls with counts ranging 70 000 - 10 000)
    7 614, ~ kernel32.dll!CreateToolhelp32Snapshot+0x2d6
    6 713, ~ kernel32.dll!Thread32First+0x77
    6 713, ~ kernel32.dll!Thread32First+0xb0
    5 931, ~ kernel32.dll!Process32FirstW+0x7a
    5 931, ~ kernel32.dll!Process32FirstW+0x98
    5 931, ~ kernel32.dll!CreateToolhelp32Snapshot+0x28f
             (other 13 calls with counts ranging 5 000 - 100)
             (other 460  calls with counts ranging 50 - 1)


Function calls marked with (~) were incrementing their PF counts just occasionally (but all together), once in a couple of tens of seconds - apparently when TTh was enumerating existing processes and their threads (using kernel32.dll's "CreateToolhelp32Snapshot" + "Process/Thread32First/W" + "Process/Thread32Next/W").
Function calls marked with (+) are incrementing their PF counts continuously (the counters are being incremented each second).

However I was no sure anymore with what is causing occasional calls to "ntoskrnl.exe!TmCurrentTransaction" (increments in big jumps), whether it could be possible to reduce calls to "win32k.sys!EngFntCacheLookUp", "ntoskrnl.exe!ExGetPreviousMode" (happens probably in kernel mode, to check whether a kernel/user mode switch for a call has happened?). ("DpFbview.dll!Ordinal9" seems to be a driver from DigitalPersona, Inc. - belongs somehow to the fingerprint sensor on my notebook - WTH is it listed there? Is it being injected in each process??).

[fred]

Finally I could return to my "loving" thread with some new relevant information, which I found interesting (albeit posibly not useful ).

Nothing wrong with a pagefault, it's just not in real memory.
The only option is to limit the amount of programs that are running and increasing the amount of available memory.
On my 6 & 12 G machine I get 0 pagefaults.
As I checked Win 7 needs about 2.5 Gbytes, so a system with about 2 G ... doesn't have enough memory.

[Pepo]

Finally I could return to my "loving" thread with some new relevant information, which I found interesting (albeit posibly not useful ).

Nothing wrong with a pagefault, it's just not in real memory.
The only option is to limit the amount of programs that are running and increasing the amount of available memory.
On my 6 & 12 G machine I get 0 pagefaults.
As I checked Win 7 needs about 2.5 Gbytes, so a system with about 2 G ... doesn't have enough memory.

If my 4G Win7 machines are in a steady state, there is also no memory paging... If my WinXP machine with AMD Duron and 1.25 GB RAM is freshly booted, there is 1 GB RAM free and absolutely nothing HDD-related happens. Yet some applications on them continuously produce soft page faults. Some no at all, some less, some more...

No, and again no, this all is not about lack of or enough RAM (I've stated it multiple times before - it is not about hard page faults), it is rather about code calls' transitions between user/kernel modes and modifying (security + ownership) properties for RAM areas (to be allocated / deallocated).