jump?
jump?
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
I don't see anything odd or nefarious about that screenshot. The size of the idle process depends on what the system is doing (as has been said some operations are performed in the idle process), the type of CPU, the number of cores, etc.
And of course you cannot shut down the idle process. Not a trojan, not a worm, and it's a bit scary that a computer literate person thinks that the idle process isn't legit. Truthfully a really nasty virus or trojan won't show up in the task manager because it will hook into svchost. If you see a lot of svchost's then that might be a cause for concern. svchost encompasses a large number of threads that are running on the system but unfortunately with the default task manager you cannot see what they are. I believe Salem's fav guys over at SysInternals have an answer to this with their own task manager app.
Last edited by VirtualAce; 07-04-2009 at 10:54 AM.
It never even crossed my mind. I was just curious about the size of the process and wanted to know more. I was under the impression this was a fixed size, depending on the kernel. Sure, maybe the number of processors affected the size. But the math didn't add up to 28k. So I was just asking. Never really got an answer.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Sorry Mario F. I was addressing that to the OP and not you. I apologize if that was not clear. I would never question you on a simple matter such as this and hold your responses and abilities in very high regard. So to be clear I was stating the OP should know better.
That really scares me.I can't speak for the OP but I know other than programming I'm not very good with computers.
Indeed. It's like trying to become a painter without learning about color theory.
It is particularly scary in programming languages like those mostly discussed on these forums. Not only knowledge of computer and OS operation is mandatory in order to effectively use these languages for anything other than the simplest (read useless) programs, but what strikes me most chilling is the fact these languages usually provide their users with an immense incentive to learn more about the machine.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
I believe the memory used column in taskman is merely the process' working set size, and not the actual memory used, in XP. They may have changed things in recent versions of windows; I don't rightly know.
I believe this is correct. You need to use something like perfmon on Windows to accurately see the amount of memory being used by a process.I believe the memory used column in taskman is merely the process' working set size, and not the actual memory used, in XP. They may have changed things in recent versions of windows; I don't rightly know.
A proper "idle loop" will be:
But for efficiency, the idle-loop may look more like this:Code:here: hlt jmp here
As to the "amount of memory for idle", that's probably dependant on a whole lot of things, including the stack for the idle process [we can't use the current process's stack, since we may end up in idle whan the current process has run out of stack and is waiting for the stack to be paged in]. So that makes it at least 8KB (4KB for the code, 4KB for the stack).Code:L1: cmp context_switch_needed, 0 jz L2 call do_context_switch L2: cmp other_work_needed, 0 jz here call other_work_function here: hlt jmp L1
As stated elsewhere, the idle process is sometimes doing REAL WORK, in which case it will also need memory for those things.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I once had that Idle task thing, that was on Windows 7 build 7000, I havn't had it on task manager for XP, Vista or Windows 7 RC :S
Also, it did scare me when I first saw it, like I looked at the CPU usage only and it said 99%, that gave me a shock...
Also, I always have a load of those svhost processes, I always think the OS has some bug which makes it start it over and over again...
Currently research OpenGL
Okies, been taking a look at the innards of working sets, which essentially forced me to revisit the whole memory management thingy.
It's quite curious I never see a change on my Idle Process working set size. It boots on 16k and stays on 16k no matter what I do. With 3Gb RAM and with a very conservative memory usage, I'd expect less aging of the working sets. But I gather many things can affect this; like prefetch and an apparent preference for aged working sets over "free" memory, when handling soft faults.
It however becomes established that the discrepancy in values of the Idle Process size report on XP is mostly a function of total system RAM. Thanks.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Apparently the Idle loop runs at dispatch level (it's the last paragraph) so that'd explain it. At that level it can't use anything that'd need to be paged back in, because the page fault handling interrupt has been masked off as that runs at APC_LEVEL (the level below).
Everything it uses must stay resident, and it's most probably not allocating anything itself so it stays at a constant level. As for why 16K, no idea, but one can hazard a guess; a page for its KTHREAD, 2 pages of code, one for the kernel and one for the hal, and a page for the DPC list and/or other related structures.Originally Posted by http://msdn.microsoft.com/en-us/library/ms795133.aspx
Windows runs services inside host processes which are called, creatively, "svchost.exe." It can run more than one service in a single process, although it doesn't always. It is impossible to kill svchost.exe because that is not the proper way to terminate a service -- you terminate services using the control panel administrative plugin, or by the "net stop" command on the command line.
I'm kind of disturbed that people don't seem to have ever looked at the task manager before, then are shocked at mundane things. God forbid you use Process Explorer...
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}