ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
It is about one week that I am looking for a way to assess cup time of a linux process. By cpu time, I mean the amount time, a process really uses cpu.
Today, I used getrusage() (in sys/resources.h) and clock() (in time.h) but unfortunately it returns the amount of time that the process is in the scheduler. What I need is the amount of time in mili-seconds precision that a process uses cpu.
I need this because I want to assess the cpu time of a real-time application.
Another very good possibility is that very-broad category of facility called accounting.
The original concept for this kind of facility hails from the days when computer resources were very expensive and had to be paid-for. (Actually, shortage of such resources is why a couple of researchers in the 1970's took a "cast-off" "toy" DEC PDP-7 and used it to make history...)
But this, or something like it, might be just-the-ticket for what you are wanting to do. You want a historical record of system activity that will impose a fairly constant impact upon the system: an impact that is continuous enough that you can "factor it out." If you run a particular workload over a period of time, you want to be able to draw-off an [i]accumulation[/u] of data, after the fact, that you can easily analyze statistically.
You know that the overhead of collecting accounting-records is "there," but you also know that this overhead will be a fairly-steady percent of the total time used. You'll be able to learn about the runtime characteristics of this workload over time, without worrying too much that "the presence of the researcher changed the outcome of the experiment."
Your both philosophical and historical replay made me so happy and broaden my eyes. Unfortunately theNbomr's command did NOT work for me. This just did like getrusage().
On the other hand, I am studying "artificial intelligence" which prevents me from tackling the problem from its base. So, I think the best and fastest solution is to find a shortcut to prevent the system from doing any context switching even handling any other process's or system's interrupts. This maybe possible by giving the most priority to the process or handling context switching signals in an unusual way (which I am not familiar with any of them).
Its going to be difficult to get the precision you desire from user level on a non-real-time operating system. You have the system+user time charges, but those are gross-level counters, and always have been.
Increasing process priority will serve no purpose if only one process is essentially running - there's no competition. And you don't want to disable interrupts, or there goes your clock timer too. An no other processes will run either, so you already know the answer to "how much cpu time does a process use": Answer; all of it.
If your application is a real-time application, it can't be run as such under Linux. Linux is not a real-time OS.
For the benefit of others reading and contributing to this thread, can you please expand on what you mean by 'the amount of time that the process is in the scheduler', and contrast that to what you actually want?
By "the time the process is in scheduler" I mean the amount of time a process is in Linux scheduler to be served by the CPU and it is not necessarily equal (it is greater than or equal) the amount, the process uses the CPU really.
Soosho - the kernel does a fairly good job of only charging time to a process for kernel code, when that kernel code is running on the program's behalf (eg system calls, not disk wait, not idle time). It does not charge for other kernel book keeping. But it can't be perfect - the OS is a shared resource, shared by all the processes; as such, the accounting times will not add up perfectly. If you code needs to fault in a page, should that page fault code time be charged to your processes sys time ? It should, because it was your system that used it. On the other hand, perhaps it shouldn't because the system could have faulted in all pages before your program started and wired them down. It is in these subtle areas that distinguish a real-time OS vs a standard *nix kernel.
By "the time the process is in scheduler" I mean the amount of time a process is in Linux scheduler to be served by the CPU and it is not necessarily equal (it is greater than or equal) the amount, the process uses the CPU really.
That's a nice recursive answer...
Classically, a process is in one of three states: sleeping/blocked, ready, or running. A process that exists is always 'in the scheduler' in one of these states (neglecting a small number of special states: zombie, stopped, maybe others). In large part, that is what makes it a process.
Are you suggesting that a process's accounted-for time includes other than the time it spends in the 'running' state? While I have no conclusive knowledge to the contrary, this seems nonsensical to me. What purpose would be served in reporting anything other? How are you reaching a conclusion about this?
Inquiring minds want to know.
Are you trying to distinguish 'user time' from 'kernel time'? Kernel time is the time spent by the kernel on behalf of the process; that is, servicing a system call. User time is just the process execution of code in user space. If this distinction is what you want, then the time command does report the two components separately.
You misunderstood me. As I mentioned in post #1, I am NOT looking for the time that the process is in scheduler but the time a process really uses the CPU. In other words, I am looking for the total amount of time a process is in running state (this means total amount of time that CPU consumes to execute assembly instructions of the process one after the other, and NOT the time when the process is in other states like (sleeping, blocked, ready, zombie and anything OTHER than running state))
Okay, that's what I thought. So what makes you think the numbers reported by time include anything other than the run state? If the 'time in the scheduler' included all of those other states, it would be equal to the so-called 'wall time', which is also reported.
--- rod.
Dear Mr. C., thanks a lot for your details, particularly those distinguishing between real-time and shared resource OS. As you mentioned there is no way to calculate the running time of a process (total amount of time that a process is in running state ( its assembly instructions are running on the CPU.)). I remember, once a friend manipulated a Linux kernel to not context switch when it is busy running a process until the CPU finishes with the process. But as you pointed out, page fault handling time should be considered again. Am I wright?
I would be beneficial if you stop saying "the time the process is in the scheduler". This is backwards.
The kernel scheduler runs on its own behalf when it wants. The scheduler places the process on one of many queues. Upon leaving kernel mode, the next ready to run process is set to run, and the kernel returns control to that process.
The time reported by getrusage tells you the time a) the process was running in its own address space, and b) the time the process was charged when the kernel ran system calls requested by the process. The kernel is not charging a process time when it does its own work (like scheduling, interrupt handling, memory management). So, rusage times *do not include* those extra activities.
There are only a couple of entries points into the kernel: system calls, fault events, interrupts. For a clock interrupt, your process is charged one tick (based on HZ). For other interrupts, the user's rusage times are incremented based upon the current time. Same with faults.
These dispatch into the kernel very quickly. If you are trying to determine the timings of those, place instrumentation into each of those entry points.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.