LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Password
Linux - Kernel This forum is for all discussion relating to the Linux kernel.

Notices

Reply
 
Search this Thread
Old 09-28-2012, 11:52 PM   #1
DKSL
LQ Newbie
 
Registered: Apr 2012
Posts: 29

Rep: Reputation: Disabled
Understanding /proc/pid/sched


I am trying to understand the output of the /proc/pid/sched. Dose any one have a good idea about what these fields mean?

se.exec_start : 682057.318915
se.vruntime : 561276.188450
se.sum_exec_runtime : 238.118766
nr_switches : 393
nr_voluntary_switches : 44
nr_involuntary_switches : 349
se.load.weight : 1024
policy : 0
prio : 120
clock-delta : 1291

Specially I would like to know about se.sum_exec_runtime and clock-delta.
 
Old 10-01-2012, 10:43 AM   #2
suttiwit
Member
 
Registered: Aug 2012
Location: Chiang Mai, Thailand
Distribution: Kubuntu 12.10 x86_64
Posts: 192
Blog Entries: 2

Rep: Reputation: 22
What are you trying to achieve?
 
Old 10-01-2012, 11:59 AM   #3
DKSL
LQ Newbie
 
Registered: Apr 2012
Posts: 29

Original Poster
Rep: Reputation: Disabled
I want to measure process CPU usage time and wondering if se.sum_exec_runtime gives that value?
 
Old 10-01-2012, 10:31 PM   #4
suttiwit
Member
 
Registered: Aug 2012
Location: Chiang Mai, Thailand
Distribution: Kubuntu 12.10 x86_64
Posts: 192
Blog Entries: 2

Rep: Reputation: 22
what is a cpu usage time?
 
Old 10-02-2012, 12:18 AM   #5
DKSL
LQ Newbie
 
Registered: Apr 2012
Posts: 29

Original Poster
Rep: Reputation: Disabled
when you execute the time it sends on the CPU, maybe its called the CPU time-slice.. I periodically take a record of the /proc/pid/sched file with different priority levels. The ultimate goal is to see if a high priority would result in a high se.sum_exec_runtime value. will se.sum_exec_runtime give the CPU usage time?
 
Old 10-02-2012, 01:01 AM   #6
DKSL
LQ Newbie
 
Registered: Apr 2012
Posts: 29

Original Poster
Rep: Reputation: Disabled
what is the units of this field(se.sum_exec_runtime)? is it nano seconds?
 
Old 10-02-2012, 04:00 AM   #7
suttiwit
Member
 
Registered: Aug 2012
Location: Chiang Mai, Thailand
Distribution: Kubuntu 12.10 x86_64
Posts: 192
Blog Entries: 2

Rep: Reputation: 22
Quote:
Originally Posted by DKSL View Post
what is the units of this field(se.sum_exec_runtime)? is it nano seconds?
Well, if you mean that: the amount of time that the CPU processes something then, it is possible its nanosecond.
 
Old 10-02-2012, 09:30 AM   #8
DKSL
LQ Newbie
 
Registered: Apr 2012
Posts: 29

Original Poster
Rep: Reputation: Disabled
Have any idea about how to calculate this value theoretically? when priority (nice) values are changed, so I can compare with the experimental value and do a comparison. Also to begin things I found in another link http://www.linuxquestions.org/questi...ed-4175412750/ that the se.sum_exec_runtime can be calculated using utime(time spent in userspace) & stime(time spent in kernel space). Any idea on how to do this?
 
Old 10-02-2012, 02:41 PM   #9
sundialsvcs
Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 5,377

Rep: Reputation: 1108Reputation: 1108Reputation: 1108Reputation: 1108Reputation: 1108Reputation: 1108Reputation: 1108Reputation: 1108Reputation: 1108
If you really want to get to the bottom of these things, you simply have to turn to the one truly-authoritative source: the kernel source-code, which can easily be browsed on-line e.g. at http://lxr.linux.no/.

In this case, the operative routine is proc_sched_show_task which is found in /kernel/sched/debug.c. (It is called from /fs/proc/base.c.

The Achilles Heel of your current approach is that "the presence of the experimenter changes the outcome of the experiment." Your (of course, very active...) monitoring program is consuming CPU cycles, too. In fact, it is competing with the very thing that you are attempting to measure; thereby invalidating any results obtained.

The actual CPU-allocation performance of any process on the system is, from nanosecond to nanosecond, completely affected by every other process that surrounds it; by their exact (and unpredictable) execution-time demands, and by everything ("else") that the system may be doing at the time.

The "nice" value has at best only an indirect influence upon the scheduler's behavior ... as does every other factor that the scheduler is programmed to consider. In fact, the scheduler is programmed to strike a balance between several conflicting goals ... "We want to favor this task but we must not starve that one," and so on.

If you want to fairly gauge the progress of a task, you should build that instrumentation into that task, and you should do so in terms of what 'that task' is doing, i.e. "for the business" and in terms of "business-oriented bright line rules." For example, many decades ago(!) I had to assess the performance of a batch-processing system in order to determine whether new hardware needed to be purchased to support it. To do so, I postulated that "90% of class-A jobs must begin execution within 60 seconds of being submitted, and must complete within 120 seconds thereafter." (Two separate rules.) I didn't care about dispatching algorithms or time slices or any of that ... I framed my inquiry in terms of "out-the-door, important-to-clients results (or lack thereof)." And I was able to base my assessment entirely upon historical data. I plotted whether-or-not these jobs actually met those standards. "Yes," or "No" ... "and don't bother to ask for excuses."

The notion here is the same: "What you really want to know is whether-or-not the system 'passed' or 'failed' your test, whatever 'your test' may happen to be." You set up an experiment and gather data. Then, you change one experiential parameter and repeat the experiment. You gather data in a way that doesn't influence the outcome because it remains constant throughout. And, you structure the experiment, not in terms of the ("who cares, anyway ...?") Linux scheduling algorithms ... but strictly in terms of what you need to know in order to address the underlying business problem ... and in such a way that it clearly points the way to a strategy that you can implement (and test!) right now.
 
  


Reply

Tags
debug, kernel, linux, proc, scheduler


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can someone explain the output of /proc/pid/sched vinaywagh Linux - Newbie 4 06-26-2012 08:02 PM
interpretation of /proc/pid/sched output GoelMudit Linux - General 1 01-06-2011 10:54 PM
Print all PID folders from /proc line-by-line with this format (( PID: command-line )) courteous Linux - Newbie 7 12-12-2010 04:47 PM
pmap or /proc/<pid>smap or /proc/<pid>/status iQoder Linux - Newbie 1 07-16-2009 06:32 PM
how to read /proc/pid/status in sched.c linuxdoniv Programming 3 07-21-2008 09:49 PM


All times are GMT -5. The time now is 05:55 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration