Re: WORKING_SET.COM gives all COM states when run at high priority

From: Jeff Cameron (roktsci_at_comcast.net)
Date: 06/30/05 

Date: Wed, 29 Jun 2005 22:53:55 -0700

On 6/29/05 9:19 PM, in article
1120105148.505681.16650@o13g2000cwo.googlegroups.com, "AEF"
<spamsink2001@yahoo.com> wrote:

>
>
> David B Sneddon - bigpond wrote:
>> AEF mentioned in passing:
>>>
>>> Jeff Chimene wrote:
>>>
>>>> AEF wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> WORKING_SET.COM, which is in SYS$EXAMPLES, lists all processes and
>>>>> various working set statistics for each. I recently found out that when
>>>>> you run it at high priority, most or all of the states show up as COM.
>>>>> The state is determined by the function
>>>>>
>>>>> f$getjpi("","STATE")
>>>>>
>>>>> The higher the priority, the higher the percentage of states which are
>>>>> reported as COM.
>>>>>
>>>>> Why should the result of this function be dependent on the priority at
>>>>> which it is run?
>>>>
>>>> Because your process running working_set.com is using all the CPU? All
>>>> other processes are forced to non-CUR states, e.g. COM
>>>>
>>>> For extra credit, code up a real-time CPU-burner that also
>>>> allocates/frees a few mebibytes of VM. Fire off a few of those and watch
>>>> with working_set.com
>>>>
>>>> Cheers,
>>>> jec
>>>
>>>
>>> Thanks for your rapid response! But some of my processes are idle
>>> terminal sessions. Why are they waiting for the CPU?
>>
>> Does $GETJPI not operate within the context of the process
>> you want the information about? In which case that process
>> would need to "run" to return the information...
>
> I don't see how this can be. If $getjpi ran in the target process's
> context, wouldn't its result go into a symbol in that target process
> and screw it up? Also, if the target process needs to run $getjpi than
> I'd expect to see processes all show up as CUR, since they are running
> as you say.
>
It wont be CUR because you are the process that has commanded the operation
and while the information that was fetched from the other process is being
placed in your memory area it is running under the context of your process.
Since the other process has already handed off the data back to you, it
still has a few more instructions to do under it's context to get back to
the state it was in before you asked it for its information.

Jeff

Relevant Pages

  • Re: WORKING_SET.COM gives all COM states when run at high priority
    ... Why are they waiting for the CPU? ... If $getjpi ran in the target process's ... context, wouldn't its result go into a symbol in that target process ... if the target process needs to run $getjpi than ...
    (comp.os.vms)
  • Re: WORKING_SET.COM gives all COM states when run at high priority
    ... if the target process needs to run $getjpi ... The getjpi does a kernel AST into the target process and runs within that ... the target process context, not the inquirers. ...
    (comp.os.vms)
  • Re: Injected DLL causes process termination - occasionally
    ... I would recommend debugging the child process in order to get a better feel for why your attempt is failing. ... // Allocate memory in the target process ... pWriteBuffer = VirtualAllocEx(pi.hProcess, pWriteBuffer, ... // Change the execution context of the the primary thread of the ...
    (microsoft.public.win32.programmer.kernel)
  • Injected DLL causes process termination - occasionally
    ... My injected code is indeed called, ... // Allocate memory in the target process ... pWriteBuffer = VirtualAllocEx(pi.hProcess, pWriteBuffer, ... // Change the execution context of the the primary thread of the ...
    (microsoft.public.win32.programmer.kernel)
  • Re: WORKING_SET.COM gives all COM states when run at high priority
    ... for those items not available from non-paged pool. ... > context, wouldn't its result go into a symbol in that target process ... $GETJPI executes special kernel ASTs to get information from P1 space ... CUR is a process that has work to do and currently has a CPU devoted ...
    (comp.os.vms)