I need to start a external program and wait until it ends. After it was running I nead peak memory usage and CPU time oder CPU tiks.
How can I do this in C / Objective-C on OSX 10.11?
I looked at NSTask, but I have no idea how to get peak memory usage and CPU time.
You can get the PID by calling -processIdentifier and then use Mach's task_info() function to get the information you seek. See: Memory used by a process under mac os x
I believe task info should be available until the process is waited, so just be sure to do that after the process finishes.
Related
Initializing CUDA in a newly-created process can take quite some time as long as a half-second or more on many server-grade machines of today. As #RobertCrovella explains, CUDA initialization usually includes establishment of a Unified Memory model, which involves harmonizing of device and host memory maps. This can take quite a long time for machines with a lot of memory; and there might be other factors contributing to this long delay.
This effect becomes quite annoying when you want to run a sequence of CUDA-utilizing processes, which do not use complicated virtual memory mappings: They each have to wait their their long wait - despite the fact that "essentially", they could just re-use whether initializations CUDA made the last time (perhaps with a bit of cleanup code).
Now, obviously, if you somehow rewrote the code for all those processes to execute within a single process - that would save you those long initialization costs. But isn't there a simpler approach? What about:
Passing the same state information / CUDA context between processes?
Telling CUDA to ignore most host memory altogether?
Making the Unified Memory harmonization more lazy than it is now, so that it only happens to the extent that it's actually necessary?
Starting CUDA with Unified Memory disabled?
Keeping some daemon process on the side and latching on to it's already-initialized CUDA state?
What you are asking about already exists. It is called MPS (MULTI-PROCESS SERVICE), and it basically keeps a single GPU context alive at all times with a daemon process that emulates the driver API. The initial target application is MPI, but it does bascially what you envisage.
Read more here:
https://docs.nvidia.com/deploy/pdf/CUDA_Multi_Process_Service_Overview.pdf
http://on-demand.gputechconf.com/gtc/2015/presentation/S5584-Priyanka-Sah.pdf
I had this question in mind from long time and may sound little vacuous. We know that operating system is responsible for handling memory allocation, process management etc. CPU can perform only one task at a time(assuming it to be single core). Suppose an operating system has allocated a CPU cycle to some user initiated process and CPU is executing that. Now where is operating system running? If some other process is using the CPU, then, is operating system not running for that moment? as OS itself must need CPU to run. If in case OS is not running, then who is handling process management, device management etc for that period?
The question is mixing up who's in control of the memory and who's in control of the CPU. The wording “running” is imprecise: on a single CPU, a single task is running at any given time in the sense that the processor is executing its instructions; but many tasks are executing in the sense that their state is stored in memory and their execution can resume at any time.
While a process is executing on the CPU, the kernel is not executing. Its state is saved in memory. The execution of the kernel can resume:
if the process code makes a jump into kernel code — this is called a system call.
if an interrupt occurs.
If the operating system provides preemptive multitasking, it will schedule an interrupt to happen after an interval of time (called a time slice). On a non-preemptive operating system, the process will run forever if it doesn't yield the CPU. See What mechanisms prevent a process from taking over the processor forever? for an explanation of how preemption works.
Tasks such as process management and device management are triggered by some event. If the event is a request by the process, the request will take the form of a system call, which executes kernel code. If the event is triggered from hardware, it will take the form of an interrupt, which executes kernel code.
(Note: in this answer, I use “CPU” and “processor” synonymously, to mean a single execution thread: a single core, or whatever the hardware architecture is.)
The OS kernel does nothing at all until it is entered via an interrupt. It may be entered because of a hardware interrupt that causes a driver to run and the driver chooses to exit via the OS, or a running thread may make a syscall interrupt.
Unless an interrupt occurs, the OS kernel does nothing at all. It does not need to do anything.
Edit:
DMA is, (usually), used for bulk I/O and is handled by a hardware subsystem that handles requests issued by a system call, (software interrupt). When a DMA operation is complete, the DMA hardware raises a hardware interrupt, so running a driver that can further signal the OS of the completion, maybe changing the set of running threads, so DMA is managed by interrupts.
A new process/thread can only be loaded by an existing thread that has issued a system call, (software interrupt), and so new processes are initiated by interrupts.
It's interrupts, all the way down :)
It depends on which type of CPU Scheduling you are using : (in case of single core)
if your process is executing with preemptive scheduling then you can interrupt the process in between for some time duration and you can use the CPU for some other Process or O.S. but in case of Non-Preemptive Scheduling process is not going to yield the CPU before completing there execution.
In case of single Core, if there is a single process then it will execute with given instruction and if there are multiple process then states stored in the PCB. which make process queue and execute one after another, if no interrupts occur.
PCB is responsible for any process management.
when a process initialize it calls to Library function that's System calls and execution of Kernel get invoke if some process get failed during execution or interrupt occur.
I first learned about how computers work in terms of a primitive single stored program machine.
Now I'm learning about multitasking operating systems, scheduling, context switching, etc. I think I have a fairly good grasp of it all, except for one thing. I have always thought of a CPU as something which is just charging forward non-stop. It always knows where to go next (program counter), and it goes to that instruction, etc, ad infinitum.
Clearly this is not the case since my desktop computer CPU is not always running at 100%. So how does the CPU shut itself off or throttle itself down, and what role does the OS play in this? I'm guessing there's an input on the CPU somewhere which allows it to power down... and the OS can set this if it has nothing to schedule, but the next logical question is how does it start back up again? I'm guessing either one of two things:
It never shuts down completely, just runs at a very low frequency waiting for the scheduler to get busy again
It shuts down completely but is woken up by interrupts
I searched all over for info on this and came up fairly empty-handed. Any insight would be much appreciated.
The answer is that is depends on the hardware, the operating system and the way that the operating system has been configured.
And it could involve either or both of the strategies you proposed.
Another possibility for machines based on the x86 architecture, is that x86 has an HLT instruction that causes the core to stop until it receives an external interrupt. So the "Idle" task could simply execute HLT in a tight loop.
Just go to task manager, performance tab, and watch the cpu usage while you're doing absolutely nothing on your computer. it never stops fluctuating. Having an operating system like windows running, the cpu is going to ALWAYS be functioning, it never completely shuts down.
Having your monitor display an image requires your cpu to process a function allowing it to display anything. etc.
Everything runs through the CPU, just like your brain, it controls everything. nothing would function without it.
Some CPUs do have a 'wait for interrupt' instruction which allows the CPU to stop executing instructions when there is nothing to do, and will not re-awake until there is an interrupt event. This is particularly useful in microcontrollers, where they can sit for long periods of time waiting for something to happen.
Intel = HLT (Halt)
ARM = WFI (Wait for interrupt)
Sometimes a 'busy wait' is also used, where the CPU sits in a little 'idle' loop, checking for things to do. In this case, the CPU is still running instructions, but the operating system is in an idle state. It's not as efficient as using a HLT.
Modern CPUs can also adjust their power usage, and are capable of reducing clock rates, or shutting down parts of the CPU that aren't being used. In this way, power usage during an active idle state can be less than during active processing, even though the core CPU is still running and executing instructions.
If speaking about x86 architecture when an operating system has nothing to do it can use HLT instruction.
HLT instruction stops the CPU till next interrupt.
See http://en.m.wikipedia.org/wiki/HLT for details.
Other architectures have similar instruction to give CPU a rest.
I had run valgrind on a sample daemon program. The parent exits after allocating a chunk of 1000B, but the child that runs on the background keeps on allocating 200B of memory on the heap through malloc, after every two seconds.
My question is: does valgrind execute the program on the actual processor, or on a synthetic CPU?
Does it allocate the memory on the actual heap or on a synthetic RAm which doesn't exist?
Since I let the program run for a quite a long duration so much so that the child allocated some 2GB of memory on the heap. On implementing the program on massif, I got one output file for the parent, and on killing the daemon process, I got another massif.out. for the child which showed the allocation of the memory on the heap.
Valgrind run program in its own synthetic CPU, nothing from the program machine code reaches the host CPU.
Memory allocation is hooked with Memcheck, if you use it, otherwise Valgrind calls the libc memory allocation routines.
This facts may complicate Valgrind debugging of system services, indeed.
If you turn on the memcheck(which is the default), then Valgrind will manage the heap, i.e. all the memory related methods (malloc/free/memmove etc.) will be replaced by Valgrind's version of the corresponding methods.
As already told, your program is running on virtual CPU created and managed by valgrind.
There is no notion of synthetic RAM as far I know. In any case, all this is very transparent to the running process(your daemon) and shoudl not change the behavior of your program in any way.
So the answer is YES for synthetic CPU and no for synthetic RAM.
A process P1 is executing in infinite loop in a system which has only a single CPU. There are also other processes like P2, P3 which are waiting to gain the CPU, but are in wait queue as P1 is already executing.
The program is, something like:
int main( )
{
while(1);
}
So, what will be the end result? Will the system crash?
Probable answer is, the CPU won't crash and other processes can execute in the CPU as because every process has a specific time slice, so after the time slice of P1 expires, other waiting processes can gain the CPU.
But again, how will the kernel (O/S) check that the time slice has expired, as because there is only one CPU and the process is running in infinite loop? Because if checking has to happen, it needs CPU to do that, and the CPU is already occupied by process P1 which is executing in infinite loop.
So what happens in this case?
It really depends on what operating system and hardware you are using. Interrupts can transfer the execution of code to another location (interrupt handler). These interrupts can be software (code in the program can call these interrupt handlers) or hardware (the cpu receives a signal on one of its pins). On a motherboard you have something called a Programmable Interrupt Controller (PIC) which can generate a steady stream of interrupts (timer interrupts). The OS can use the timer interrupt handler to stop a running process and continue another one.
Again, it really depends on the OS, the hardware you are working with,... and without more specifics it's too general a question to give a definite answer.
Processor has something called interutps. OS (like windows) tell processor:
- Use this process for X time and then tell me
So procesor starts timer and works on process. When time pass procesor sends interupt and tell OS that time passed. OS now will decide wwich process will work next.
Hope this answers your question.