If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
"24-core CPU and I can’t move my mouse"
"24-core CPU and I can’t move my mouse"
https://randomascii.wordpress.com/20...move-my-mouse/ "This story begins, as they so often do, when I noticed that my machine was behaving poorly. My Windows 10 work machine has 24 cores (48 hyper-threads) and they were 50% idle. It has 64 GB of RAM and that was less than half used. It has a fast SSD that was mostly idle. And yet, as I moved the mouse around it kept hitching – sometimes locking up for seconds at a time." Interesting. And he is a Google software developer for Chrome. Lynn |
Ads |
#2
|
|||
|
|||
24-core CPU and I cant move my mouse
On Wed, 12 Jul 2017 17:44:28 -0500, Lynn McGuire
wrote: "24-core CPU and I can’t move my mouse" https://randomascii.wordpress.com/20...move-my-mouse/ "This story begins, as they so often do, when I noticed that my machine was behaving poorly. My Windows 10 work machine has 24 cores (48 hyper-threads) and they were 50% idle. It has 64 GB of RAM and that was less than half used. It has a fast SSD that was mostly idle. And yet, as I moved the mouse around it kept hitching – sometimes locking up for seconds at a time." Interesting. And he is a Google software developer for Chrome. Sounds made up. I can't imagine a work machine using a SSD. Maybe the SSD is worn out. Lynn |
#3
|
|||
|
|||
"24-core CPU and I can’t move my mouse"
On 2017-07-12 18:44, Lynn McGuire wrote:
"24-core CPU and I can’t move my mouse" https://randomascii.wordpress.com/20...move-my-mouse/ Interesting. And he is a Google software developer for Chrome. Lynn Indeed. Hopefully MS fixes the problem by Fall Creator's Update... -- ! _\|/_ Sylvain / ! (o o) Memberavid-Suzuki-Fdn/EFF/Red+Cross/SPCA/Planetary-Society oO-( )-Oo "And yesterday the planet seemed to be going so well." -Dent |
#4
|
|||
|
|||
24-core CPU and I cant move my mouse
Lucifer Morningstar wrote:
On Wed, 12 Jul 2017 17:44:28 -0500, Lynn McGuire wrote: "24-core CPU and I can’t move my mouse" https://randomascii.wordpress.com/20...move-my-mouse/ "This story begins, as they so often do, when I noticed that my machine was behaving poorly. My Windows 10 work machine has 24 cores (48 hyper-threads) and they were 50% idle. It has 64 GB of RAM and that was less than half used. It has a fast SSD that was mostly idle. And yet, as I moved the mouse around it kept hitching – sometimes locking up for seconds at a time." Interesting. And he is a Google software developer for Chrome. Sounds made up. I can't imagine a work machine using a SSD. Maybe the SSD is worn out. On a build machine, one with parallelization, you want executables to launch quickly. The header files are stored on the SSD. When multiple compile processes are reading in header files, you want that process to be fast too. You should try building software like this some time, and see how it works. Try it with -j12 or whatever. If you spent a couple grand on a 24 core processor, yes, you're going to spend a hundred bucks on an SSD. With a seek time of 100usec, it's worth it. You have to get over this fixation of yours. Using the SSD as a fast source for file reads, is a great use for it. It would work even better, if NTFS wasn't a bottleneck. Paul |
#5
|
|||
|
|||
"24-core CPU and I can’t move my mouse"
Lynn McGuire wrote:
"24-core CPU and I can’t move my mouse" https://randomascii.wordpress.com/20...move-my-mouse/ "This story begins, as they so often do, when I noticed that my machine was behaving poorly. My Windows 10 work machine has 24 cores (48 hyper-threads) and they were 50% idle. It has 64 GB of RAM and that was less than half used. It has a fast SSD that was mostly idle. And yet, as I moved the mouse around it kept hitching – sometimes locking up for seconds at a time." Interesting. And he is a Google software developer for Chrome. Lynn I tested it here. I used an Insider Edition clone to test. I used "testlimit -p" and let it run for a while, then did a control-c and stopped it. That's a command line program from Sysinternals (Microsoft bought them). http://download.sysinternals.com/files/TestLimit.zip All I can say is, "don't try this at home". The interesting part was, my mouse remained responsive. But I was seeing background CPU usage (as the presumed processes were dying). I was seeing all manner of malfunctions. Cortana disappeared at one point. Task Manager took forever to open. Process Explorer (procexp.exe) would not start, or rather, it just went into a loop without its window making an appearance. That's why I suspect Process Explorer could actually see the forked processes. Task Manager would not show the 30000 processes or more that were running. I didn't get a chance to run "tasklist" and see if I could get that to work. The conclusion ? Win10 is not a multitasking OS :-) Funny stuff. It's "an OS for updating your Facebook page". In other words, "serious computing". I don't see why I'd want to build anything on this OS. Maybe WinXP would work ? If we could convince the Chrome developer to switch to WinXP for builds, we might get a WinXP version of Chrome as a side effect :-) Here's hoping. Paul |
#6
|
|||
|
|||
"24-core CPU and I can’t move my mouse"
Lynn McGuire wrote:
"24-core CPU and I can’t move my mouse" https://randomascii.wordpress.com/20...move-my-mouse/ "This story begins, as they so often do, when I noticed that my machine was behaving poorly. My Windows 10 work machine has 24 cores (48 hyper-threads) and they were 50% idle. It has 64 GB of RAM and that was less than half used. It has a fast SSD that was mostly idle. And yet, as I moved the mouse around it kept hitching – sometimes locking up for seconds at a time." Interesting. And he is a Google software developer for Chrome. Lynn I have a theory now, as to what might be going on. The thing about semaphores and spin-locks and other assorted gubbins, is they tend to hide the actual behavior under the hood. There is some actual computing going on, and this is not just some "slow code". ******* After the reboot, I ran another test. This time, not forking nearly as many processes with "testlimit -p". I started Process Explorer first, and it started fine. Then, sorted the display by PID number, with highest PID at the top of the screen. The idea being, as soon as Testlimit starts forking processes, the highest PID numbers float to the top of the screen. Then, I opened a Command Prompt (un-elevated) and testlimit -p When the counter got up to about 2000 processes, I did control-C to stop it. Testlimit controlling process, exited immediately, yielding the command prompt input. However, the children were still there. "Tasklist" shows them, for one thing. You can run tasklist in Command Prompt, and see them. And for a flash of an instant, I saw this in Process Explorer. Before Process Explorer melted down and threw an error. Note that the PID numbers are not contiguous and there are missing PID numbers probably related to forked shells (or something). testlimit 12345 Suspended testlimit 12354 Suspended testlimit 12363 Suspended In other words, the boss process I just killed, all the children are in a suspended state, not a terminated state and not a zombie state (zombie exists on Windows!). Microsoft has an "optimization" for "Apps". That's a Metro App or a UWP. https://docs.microsoft.com/en-us/win...suspend-resume Say you're playing music on the Groove music player. You click the "X" in the upper right corner (that they thoughtfully added as an afterthought). Well, when you do that, Groove doesn't really "die". It enters a suspended state, and its resources are preserved. If you start Groove again five seconds later, perhaps your tune selection is still playing... or similar crap. This doesn't go on forever of course, because that would be non-scalable. At some point, those resources need to be harvested. https://docs.microsoft.com/en-us/win...suspend-resume Now, that kind of optimization is inappropriate for a Chrome build system or for a copy of Visual Studio. As processes which are dying there, need to die. The system read cache is plenty good at preserving already read EXE image info, so the next time "cc" is started, it should start pretty fast. *If* what I'm seeing, is the "App" treatment of Processes, this is a mistake. However, I don't think Microsoft will fix this. Somebody got their yearly bonus for this idea, an idea suited to mobile, and they'll fight like the devil, to stop anyone trying to remove the optimization. So what's going to happen in the Feedback Hub when people click the "me too" button on this bug ? Dunno. Just a guess, Paul |
#7
|
|||
|
|||
"24-core CPU and I can’t move my mouse"
Paul wrote:
Lynn McGuire wrote: "24-core CPU and I can’t move my mouse" https://randomascii.wordpress.com/20...move-my-mouse/ "This story begins, as they so often do, when I noticed that my machine was behaving poorly. My Windows 10 work machine has 24 cores (48 hyper-threads) and they were 50% idle. It has 64 GB of RAM and that was less than half used. It has a fast SSD that was mostly idle. And yet, as I moved the mouse around it kept hitching – sometimes locking up for seconds at a time." Interesting. And he is a Google software developer for Chrome. Lynn I have a theory now, as to what might be going on. The thing about semaphores and spin-locks and other assorted gubbins, is they tend to hide the actual behavior under the hood. There is some actual computing going on, and this is not just some "slow code". ******* After the reboot, I ran another test. This time, not forking nearly as many processes with "testlimit -p". I started Process Explorer first, and it started fine. Then, sorted the display by PID number, with highest PID at the top of the screen. The idea being, as soon as Testlimit starts forking processes, the highest PID numbers float to the top of the screen. Then, I opened a Command Prompt (un-elevated) and testlimit -p When the counter got up to about 2000 processes, I did control-C to stop it. Testlimit controlling process, exited immediately, yielding the command prompt input. However, the children were still there. "Tasklist" shows them, for one thing. You can run tasklist in Command Prompt, and see them. And for a flash of an instant, I saw this in Process Explorer. Before Process Explorer melted down and threw an error. Note that the PID numbers are not contiguous and there are missing PID numbers probably related to forked shells (or something). testlimit 12345 Suspended testlimit 12354 Suspended testlimit 12363 Suspended In other words, the boss process I just killed, all the children are in a suspended state, not a terminated state and not a zombie state (zombie exists on Windows!). Microsoft has an "optimization" for "Apps". That's a Metro App or a UWP. https://docs.microsoft.com/en-us/win...suspend-resume Say you're playing music on the Groove music player. You click the "X" in the upper right corner (that they thoughtfully added as an afterthought). Well, when you do that, Groove doesn't really "die". It enters a suspended state, and its resources are preserved. If you start Groove again five seconds later, perhaps your tune selection is still playing... or similar crap. This doesn't go on forever of course, because that would be non-scalable. At some point, those resources need to be harvested. https://docs.microsoft.com/en-us/win...suspend-resume Now, that kind of optimization is inappropriate for a Chrome build system or for a copy of Visual Studio. As processes which are dying there, need to die. The system read cache is plenty good at preserving already read EXE image info, so the next time "cc" is started, it should start pretty fast. *If* what I'm seeing, is the "App" treatment of Processes, this is a mistake. However, I don't think Microsoft will fix this. Somebody got their yearly bonus for this idea, an idea suited to mobile, and they'll fight like the devil, to stop anyone trying to remove the optimization. So what's going to happen in the Feedback Hub when people click the "me too" button on this bug ? Dunno. Just a guess, Paul If I use taskkill /f /im Testlimit.exe I can get rid of all the suspended Testlimit.exe children. And then I can open Process Explorer again and it works properly. And the taskkill command seems to run reasonably quickly. Taskkill is a built-in in Command Prompt, a partial equivalent to "kill" in Unix. The /f means "force", the /im is the image name I want to kill. And since that name matches thousands of Testlimit.exe processes (about 120K each), they all die in about three or four seconds or so. For more info taskkill /? So the next task, is to stop the suspend thing (somehow). Paul |
#8
|
|||
|
|||
24-core CPU and I cant move my mouse
On Thu, 13 Jul 2017 02:04:07 -0400, Paul
wrote: Lucifer Morningstar wrote: On Wed, 12 Jul 2017 17:44:28 -0500, Lynn McGuire wrote: "24-core CPU and I can’t move my mouse" https://randomascii.wordpress.com/20...move-my-mouse/ "This story begins, as they so often do, when I noticed that my machine was behaving poorly. My Windows 10 work machine has 24 cores (48 hyper-threads) and they were 50% idle. It has 64 GB of RAM and that was less than half used. It has a fast SSD that was mostly idle. And yet, as I moved the mouse around it kept hitching – sometimes locking up for seconds at a time." Interesting. And he is a Google software developer for Chrome. Sounds made up. I can't imagine a work machine using a SSD. Maybe the SSD is worn out. On a build machine, one with parallelization, you want executables to launch quickly. The header files are stored on the SSD. When multiple compile processes are reading in header files, you want that process to be fast too. You should try building software like this some time, and see how it works. Try it with -j12 or whatever. If you spent a couple grand on a 24 core processor, yes, you're going to spend a hundred bucks on an SSD. With a seek time of 100usec, it's worth it. You have to get over this fixation of yours. Using the SSD as a fast source for file reads, is a great use for it. It would work even better, if NTFS wasn't a bottleneck. Too risky. Paul |
#9
|
|||
|
|||
"24-core CPU and I can’t move my mouse"
Paul wrote:
Paul wrote: Lynn McGuire wrote: "24-core CPU and I can’t move my mouse" https://randomascii.wordpress.com/20...move-my-mouse/ "This story begins, as they so often do, when I noticed that my machine was behaving poorly. My Windows 10 work machine has 24 cores (48 hyper-threads) and they were 50% idle. It has 64 GB of RAM and that was less than half used. It has a fast SSD that was mostly idle. And yet, as I moved the mouse around it kept hitching – sometimes locking up for seconds at a time." Interesting. And he is a Google software developer for Chrome. Lynn So the next task, is to stop the suspend thing (somehow). Paul It turns out, the concepts in Unix and Windows are different. I'm quite used to parents and children in Unix, and if you kill the parent, the children are harvested. Unix has fork for creating a process. Whereas Windows has CreateProcess and CreateThread, which aren't quite the same thing. One of the articles here, mentions that Task Manager has "End Process Tree", which implies the same kinds of notions as Unix. Yet, tasklist doesn't show information of that sort (if there's a parent child relationship, only Process Explorer might be calable of showing it, and Process Explorer hangs for any of these experiments where large numbers of things are suspended). If I use testlimit -p in WinXP, killing the program while it runs in Command Prompt, harvests *most* of the children. But after a couple runs, I had maybe 20-30 of them left over in Task Manager. Whereas in Win10, if I test, all children enter the Suspended state, as if they were orphans and some dependency had been ripped out from underneath them. (In other words, nobody sent them a "kill".) Taskkill removes the suspended ones, and does so quickly. So it's a mystery whether Win10 has a "process tree" and works the same way as previous OSes. The behavior isn't re-assuring, but who knows whether the code written, is written correctly. Maybe what I'm seeing is "design intent". https://bugs.chromium.org/p/chromium...tail?id=233985 https://ninja-build.org/manual.html "On Windows, commands are strings, so Ninja passes the command string directly to CreateProcess. (In the common case of simply executing a compiler this means there is less overhead.) Consequently the quoting rules are deterimined by the called program, which on Windows are usually provided by the C library. If you need shell interpretation of the command (such as the use of && to chain multiple commands), make the command execute the Windows shell by prefixing the command with cmd /c. " If you were interested in "speed" as the ninja developers claim, why would you launch a heavy-weight shell just to evaluate "&&" ? Is the problem, in fact, the harvesting of "cmd", rather than the harvesting of "cc" ? The last time I looked, I thought there was a separate ntvdm for each Command Prompt. "What's the correct way to cancel a ninja build in progress?" https://groups.google.com/a/chromium...ev/Yqak1T1x2bY With open source software development, the treatment of Windows is always second class. In my limited usage of Visual Studio, I don't think I've ever seen orphan processes left around later. I don't think I've seen that while building Firefox with their build system (and Visual Studio to provide a callable "cc"). To get any closer to this, I'd need to set up a ninja build environment, which means installing VS2015 (just to get "cc"), and downloading chromium source to feed it. That seems like a lot of work, for a little fun... To do this for a Firefox build, takes about two days of downloading files just to get all the components to use. The randomascii complainant provides an executable to test with, but on my machine it asserts a breakpoint before doing anything. And probably expects a fully armed Visual Studio as a runtime environment. I could build ProcessCreateTests.cpp as he provides source, but then, I'd need to install Visual Studio (there's a vcproj file on the download section too). The person best able to debug this, is another developer who keeps these tools resident all the time. I throw away my VS setups after I'm done with them. Paul |
#10
|
|||
|
|||
24-core CPU and I cant move my mouse
On Thu, 13 Jul 2017 09:33:32 +1000, Lucifer Morningstar
wrote: On Wed, 12 Jul 2017 17:44:28 -0500, Lynn McGuire wrote: "24-core CPU and I can’t move my mouse" https://randomascii.wordpress.com/20...move-my-mouse/ "This story begins, as they so often do, when I noticed that my machine was behaving poorly. My Windows 10 work machine has 24 cores (48 hyper-threads) and they were 50% idle. It has 64 GB of RAM and that was less than half used. It has a fast SSD that was mostly idle. And yet, as I moved the mouse around it kept hitching – sometimes locking up for seconds at a time." Interesting. And he is a Google software developer for Chrome. Sounds made up. I can't imagine a work machine using a SSD. Maybe the SSD is worn out. My machine has 6 cores, 32GB of RAM and 512MB of SSD. As with Lyn McGuire all of this stuff is lightly loaded but I have the same problems. I also have intermittent problems with intermittent lack of response to the keyboard. According to Driver Detective all my drivers were uptodate but Microsoft Trouble Shooter stepped the driver for my NVIDIA GeForce GTX 1070 back to the next earlier driver. That has had a beneficial effect on the mouse problem but the lagging of the keyboard response continues. I also have a 7 year old Dell Inspiron with a 4 core i7, no SSD and 16GB of RAM, which also has the same problem. It too is running Windows 10. I will be the first to admit that the two machines have more in common than W10. I am still searching for the answer. -- Regards, Eric Stevens |
#11
|
|||
|
|||
24-core CPU and I cant move my mouse
On 2017-07-13 02:04, Paul wrote:
Lucifer Morningstar wrote: Sounds made up. I can't imagine a work machine using a SSD. Maybe the SSD is worn out. On a build machine, one with parallelization, you want executables to launch quickly. The header files are stored on the SSD. When multiple compile processes are reading in header files, you want that process to be fast too. You should try building software like this some time, and see how it works. Try it with -j12 or whatever. If you spent a couple grand on a 24 core processor, yes, you're going to spend a hundred bucks on an SSD. With a seek time of 100usec, it's worth it. You have to get over this fixation of yours. Using the SSD as a fast source for file reads, is a great use for it. Of course! Why buy an SSD if it's to not use it? I have %temp%, Downloads, etc, all on the SSD; you obviously want temp to be fast! What I do not put on the SSD are programs like Games that take GB of space, and where I can wait 20 seconds for them to load - it leaves plenty of room on the SSD so that the wear is spread out. Of course I bought the Samsung "pro" (2 bit cells) which lasts much longer... It would work even better, if NTFS wasn't a bottleneck. Paul -- ! _\|/_ Sylvain / ! (o o) Memberavid-Suzuki-Fdn/EFF/Red+Cross/SPCA/Planetary-Society oO-( )-Oo Scotty's smoking the dilithium crystals again, Jim. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|