none
Neq quantum is zero in CPU scheduling view of xperf

    Question

  • Hi,

    I tried to use xperf to look into the CPU scheduling internals of Windows, but I have a problems with quantums.
    I was doing a quick trace as described in xperf's introductin:

    xperf -on DiagEasy
    xperf -d XperfTrace.etl
    xperf XperfTrace.etl

    The _NT_SYMBOL_PATH variable is set to the MS symbol server, and it seems working, because when I turned on Trace/Load Symbols, it downloaded a lot of pdb files in the c:\symbols folder.

    However, in the CPU Scheduling view for every context switch the quantum is 0 for the new thread. As far as I understand it should not be zero, because then the new thread should not be running:) Here is an excerpt from the details table:

    NewProcess, NewThreadId, Count, Sum:TimeSinceLast (us), NewInSwitchTime (us), SwitchInTime (s), NewInPri, NewQnt, OldProcess, OldThreadId, OldOutPri, OldQnt, OldInSwitchTime (us), OldState, OldWaitReason, OldWaitMode, Cpu, IdealCpu
    System (4), 152, 1, 999627.327, 9.219, 8.571696402, 15, 0, Idle (0), 0, 0, 0, 14759.697, Running, Executive, NonSwap, 0, 0
    hh.exe (1656), 2904, 1, 199550.222, 42.184, 8.556894521, 10, 0, csrss.exe (412), 528, 13, 0, 22.070, Waiting, WrUserRequest, NonSwap, 0, 0

    Do I have to set anything special to get the new quantum values, any other stackwalks to turn on? (I turned on debug in bcdedit)

    Thanks for the help,
    Zoltan Micskei


    Thursday, February 19, 2009 9:58 AM

Answers

  • Hi Zoltan,

    This turns out to be a bug in the CPU scheduling summary table. The column name should read PreviousCpuIdleState, not NewQnt. Meaning of the underlying instrumentation in the OS has changed from new quantum to previous CPU Idle state with Vista. This will be fixed in the future version of WPT.

    It's expected to always see C0 (Active) for virtual CPUs. If you capture the trace on a non-virtual system you'll see this value changing (as you've observed with a trace from your physical machine).

    Hope this helps,
    Michael

    Saturday, February 28, 2009 11:07 PM
    Owner

All replies

  • Hi Micskei,

    What OS are you capturing the trace on?

    Thanks,
    Michael
    Tuesday, February 24, 2009 1:00 PM
    Owner
  • Hi,

    Sorry, I forgot that. I tried this on a Windows Vista SP1 and a Windows 7 Beta, but it just striked me that both were virtual machines run under VMware Workstation.

    Now I tried it on my physical machine (Windows Vista SP1 ENG Business), and xperf is showing quantums other than 0.

    Is this a known behaviour under virtual machines? Or is it the result of the VMware Tools (I did not tried it under MS VirtualPC)?

    Thanks for the help,
    Zoltan
    Tuesday, February 24, 2009 2:05 PM
  • Hi Zoltan,

    This turns out to be a bug in the CPU scheduling summary table. The column name should read PreviousCpuIdleState, not NewQnt. Meaning of the underlying instrumentation in the OS has changed from new quantum to previous CPU Idle state with Vista. This will be fixed in the future version of WPT.

    It's expected to always see C0 (Active) for virtual CPUs. If you capture the trace on a non-virtual system you'll see this value changing (as you've observed with a trace from your physical machine).

    Hope this helps,
    Michael

    Saturday, February 28, 2009 11:07 PM
    Owner
  • Micheal,

    Thanks for looking into the problem and the answer!

    Zoltan
    Wednesday, March 04, 2009 2:09 PM
  • Hi all,

    I am using a physical Windows 7 64bit machine. When looking at xperf (version 4.6.7231) Kernel traces with the command:
                 xperf -on proc_thread+loader+cswitch+dispatcher -stackwalk cswitch+readythread

    the table summary for the CPU Scheduling graph always indicate a value of -1 for both NewQnt and OldQnt , here are my questions:

    a) it does not seem that NewQnt should still be interpreted as Previous C-state as described in Michael's answer above, does anybody know how it should be interpreted now?
    b) how should OldQnt be interpreted?
    c) Is there any way to get the values of the thread quantums (or cycletimes)?

    Thanks!
    Friday, January 29, 2010 11:01 AM