Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am working on a time-consuming computation algorithm and want to run it as fast as possible.
How much presence (running algorithm under it) of Operating System (Windows or Linux) slows the process?
Is there any example of "OS" specifically implemented to run predefined program?
First of all I'd like to introduce that I am also working on a very similar topic time-consuming computation algorithm! So much common here OR maybe just a co-incidence...
Now,let's proceed to the answer section :-
Presence of the process(your algorithm which is running) in OS is affected by daemons and other available user programs waiting in the ready queue depending on the scheduling algorithm applied by your OS. Generally, daemons are always running and some of the system applications related process just preempts other low-priority processes(maybe like your's if your process has lower priority,generally system processes and daemons preempt all other processes). The very presence of OS(Windows Or Linux)---I am considering only their kernel here--- doesn't affect as the kernels are the manager of the OS and all process and tasks. So,they don't slow the process but daemons and system processes are heavy one and they do affect your program significantly. I also wish if we could just disable all the daemons but they are just for the efficient working of OS(like mouse control,power efficiency,etc) all in all...
Just for an example, on Linux and Unix based systems, top command provides an ongoing look at processor activity in real time. It displays a listing of the most CPU-intensive tasks on the system.
So, if you will execute this code on a Linux system,you'll get the result of all the heavy processes which are intensely consuming memory! here, you'll find that apart from your process which is heavily utilising memory there are several daemons like powerd, moused, etc., and other System processes like Xorg,kdeinit4,etc... which does affect the user processes !!!
But, one thing is clear that each process or daemons generally won't occupy more memory than your intense computation algorithm process! The ratio will be lesser instead may be one-eighth,one-fourth!!!
UPDATE BASED ON COMMENTS :-
If you're specifically looking for the process to be running on the native hardware without OS facilitation/installation---you have got two choices.
Either develop the code in machine-level language or assembly languages or other low-level languages which will directly run your process on the hardware without the need for OS to manage memory sections and all and other system processes and daemons!
Second solution is to develop/utilise a very minimal OS comprising of only those settings which are required for your algorithmic program/process! And,then this minimal OS won't be a complete OS---thereby lack of daemons,multiple system calls as in major OS' like Windows,Linux,Unix,etc.
One of the useful link which Nazar554 has provided in the comment section.I'll just quote him :-
if you really want to remove any possible overhead you can try:
BareMetal OS
In your case,it seems you are preferring the first option more than the other. But,you can achieve your task in either way!
LATEST EDIT :-
It's just a feedback from myside as I couldn't get you more clearly! It would be better if you ask the same question on Operating Systems Beta as there are several experts sitting to answer all queries regarding OS development/functionality,etc! There you'll receive a more strong and positive response regarding every single tiny detail which is relevant to your topic that I might have missed.
Best wishes from myside...
The main idea in giving processor to a task is same among all major operating systems. I've provided a diagram demonstrating it. First let me describe this diagram then I'll answer your question.
Diagram Description
When a operating system wants to execute some tasks simultaneously, it can not give processor to all of them at once. Because processor can process a single operation at a time and it can't do more that one tasks processing at the same time. Because of it OS shares it among all tasks in a time-slot by time-slot manner. In other words each task is allowed to use the processor just in its own time slot and it should give the processor back to the OS once its time slot finished.
Operating systems uses a dispatcher component to select and dispatch a pending task to give the processor to it. What is different among operating systems is how the dispatcher works, What does a typical dispatcher do? in simple words :
Pick next pending task from the queues based on a scheduling algorithm
Context switching
Decide where the removed task (from processor) should go
Answer to your question
How much presence (running algorithm under it) of Operating System (Windows or Linux) slows the process?
It depends on:
Dispatcher algorithm (i.e. which OS do you use)
Current loads on the system (i.e. how much applications and daemons is running now)
How much priority have your process task (i.e. real-time priority, UI priority, regular priority, low ,...)
How much I/O stuff is going to be done by your task (Because I/O requesting tasks usually are scheduled in a separate queue)
Excuse me for my English issues, because English isn't my native language
Hope it helps you
Try booting in single-user mode.
From debian-administration.org and debianadmin.com:
Run Level 1 is known as 'single user' mode. A more apt description would be 'rescue', or 'trouble-shooting' mode. In run level 1, no daemons (services) are started. Hopefully single user mode will allow you to fix whatever made the transition to rescue mode necessary.
I guess "no daemons" is not entirely true, with wiki.debian.org claiming:
For example, a daemon can be configured to run only when the computer is in single-user mode (runlevel 1) or, more commonly, when in multi-user mode (runlevels 2-5).
But I suppose single-user mode will surely kill most of your daemons.
It's a bit of a hack, but it may just do the job for you.
Related
I know deadlocks was a hot research topic in past. But, even though I studied lots of modern operating systems, I cannot see any major problem about deadlocks now. I know some (most) resources which deadlocks can occur strictly managed by operating system itself and seems it prevent deadlocks someway, I really didn't see any case related to a deadlock. I know lots of features about resources handled different than others in popular systems with different design principles but, they can all maintain system deadlock-free.
Try to use two mutexes in your program and in first thread close in sequence: mutex1, sleep(500ms), mutex2, in second thread: mutex2, sleep(1000ms), mutex1.
In systems. In windows (including 8.1) if your application uses SendMessage and broadcast HWND_BROADCAST - if one application is hung, your application also will be in hung state. Also in part cases of DDE communication (including ShellExecute for part of programs), if one application is not responsive, your application can be in hung state.
But you can use SendMessageTimeout...
The deadlock will always be possible if processes or threads will be synchronized. Synchronization of processes and threads is a "must-have" element of applications.
AND... SYSTEM-WIDE deadlock (Windows):
Save all your documents before this action.
Create HWND h1 with parent=0 or parent=GetDesktopWindow and styles 0x96cf0000
Create HWND h2 with parent=h1 and styles 0x96cf0000
Create HWND h3 with parent=h2 and styles 0x56cf0000 (here must be a child window).
Use ::SetParent(h1, h3);
Then click any of these windows.
The system will in cyclic (triangle) order try to reorder windows. The application is hung but if any other application will try to use SetWindowPos, the application will newer return from this function. The Task Manager won't help, the Alt+Ctrl+Del also stops to work. 100% of usage of CPU... Only hard reset will help you.
There is possibility to prevent it but this situation must be detected ASAP.
Operating system deadlocks still happen. When a system has limited contended resources that it can't reclaim a deadlock is still possible.
In linux, look at kernel stalls, these happen when I/O doesn't release in a timely manner. Kernel stalls are particularly interesting between vmware and guest operating systems.
For external instigators, deadlocks happen when san systems and networks have issues.
New release deadlocks happen fairly often while maturing a kernel, not per user, but as a whole from the community.
Ever get a blue screen or instant reboot? Some of those are caused by lost resources.
Kernels are fairly mature, and have gotten good at reclaiming resources, but aren't perfect.
Most modern resource handlers tend to present as services now instead of being lockable objects. Most resource sharing within the operating system relies on separate channels, alleviating much of the overlap. There's a higher reliance on queues and toggles instead of direct locking contention on shared buffers. These are generalities of trends in OS parts and pieces that contribute to less opportunity for deadlocks, but there's not a way to guarantee a deadlock less system.
I think my questions are unusual, but I wanna work on real time targeting in MATLAB Simulink, but I don't want to use XPC target. I just want no interrupt on the program (simulink) when it is running in order to have a real time interruptless control system. and in that order i can use my control module without target system.
first of all, please ignore my weak english. and I have some questions:
1. can we force a core to only be used by simulink and nothing else?
2. how much usually (and how much maximum) does an interrupt take time?
3. is there any other way that we can use in simulink?
thank you
a. In case you have a multicore platform: Stay away from core 0. Windows assigns certain tasks specifically to core 0. See the SetThreadAffinityMask function to get information how to run a thread on specific cores.
b. Possibly raise the thread/process priority. See the SetThreadPriority function and the SetPriorityClass function for details about setting priorities and Scheduling Priorities for dertails about the priority ranges.
Priority class REALTIME_PRIORITY_CLASS with thread priority THREAD_PRIORITY_TIME_CRITICAL will run your thread at utmost priority whenever it is ready to run. Be aware that such a priority setting will disallow any other process/thread to gain CPU on that core while your thread is running.
Well, Simulink is essentially a single-threaded application. There are some ways in which you can use a second core when running in Rapid Accelerator mode (see documentation), but by and large, everything runs on one core. I'm guessing it may change in the future, as a lot of people would like to split the execution of a single large model across multiple cores, but right now it's not possible as far as I know.
Simulink, however is not a real-time application, given that it runs on Windows or other non-real time O/S. Why do you not want to use xPC Target? As you are working on a real-time target, that would be the best option. Other options would be to use Real-Time Windows Target, SIL or even PIL if you have access to your real-time target hardware. Have a look at the example Software and Processor-in-the-Loop (SIL and PIL) Simulation. I think you can configure the code generation process to be executed on one core only, but better to ask MathWorks to be sure.
Using imageCFG you can preset affinity of a program. It modifies the exe file to run on desired core.
http://www2.robpol86.com/guides/ImageCFG/
I'm not quite understanding one sentence from WIKI about the System Call "The operating system executes at the highest level of privilege, and allows applications to request services via system calls, which are often executed via interrupts; an interrupt automatically puts the CPU into some required privilege level, and then passes control to the kernel, which determines whether the calling program should be granted the requested service."
How physically can an CPU be put into a certain privilege level and what does it mean by passing the control to kernel? Please explain these in the CPU-registers level.
This is an excellent question and privilege levels are one of the most beautiful concepts of Operating Systems.
This forum however is not the right place to ask.
However since you've asked, I'll paint you a general picture. Now you know that the OS does a lot of scheduling of processes. The scheduler must be called at periodic intervals. The CPU maintains a counter which causes a Timer interrupt.
The code which handles the Timer interrupt calls the scheduler. Now during scheduling OS level data structures are modified (process queues, etc.). At this point, if the user program were to be active for some reason, it can mess with those data structures leading to a crash.
This is handled via privilege levels. So, during scheduling, the CPU is said to be in a privilege mode - the kernel mode. The user programs can't access the CPU now.
Here comes the awesome part now. If suppose this switch in privilege level was to be made by the software, if there was a command, it could potentially be exploited by malicious user programs.
For this reason, we can't rely on the software to do the switch. We need hardware support.
The hardware is designed so that receiving interrupts sets the "privilege bit register". When the interrupt code is finished (scheduling is done), the return causes the hardware to clear the bit.
The interrupt handling code is located in a protected area in the memory reserved for OS code. User programs can't access this code (If it tries to access that part of the memory, an exception is thrown by the hardware).
Thus sanity is preserved.
How is the multitasking implemented at the basic level ? To clarify my question, lets say we are given a C runtime to make an application which implements multitasking, which can run only one task at a time on a single core processor, say, by calling main() function of this "mutlitasking" application.
How do standard OS kernels implement this ? How does this change with multicore processors
OS sets an interrupt timer, and lets the program run. Once the timer expires, control flow jumps to code of the OS for context switch.
On the context switch OS saves registers and supporting data of the current process and replaces it in CPU with data of the next process in queue. Then it sets another interrupt timer and let the next program run from where it was interrupted.
Also a system call from the current process gives control to the OS to decide if it is time for a context switch (eq. process is waiting for an IO operation)
The mechanics is transparent for programs.
Run. Switch. Repeat. :)
I've not done much work with multi-core processors, so I will refrain from attempting to answer that part of the query. However, with uniprocessors, two strategies come to mind when it comes to multi-tasking.
If I remember correctly, the x86 supports hardware task switching. (I've had minimal experience with this type of multi-tasking.) From what I recall, when the processor detects the conditions for a task switch, it automatically saves all the registers of the outgoing task into its Task State Segment (x86), and loads all the registers from the incoming task's Task State Segment. There are various caveats and limitations with this approach such as the 'busy bit' being set and only being able to switched back to a 'busy task' under special conditions. Personally, I do not find this method to be particularly useful to me.
The more common solution that I have seen is task switching by software. This, can be broken down into cooperative task switching and pre-emptive task switching. If you are coding up a cooperative task switching strategy, a task switch only occurs when the task voluntarily gives up the processor. In this strategy, you only need to save and load the non-volatile registers. If a pre-emptive strategy is chosen, then a task switch can occur either voluntarily, or non-voluntarily. In this case, all the registers must be saved and loaded. When coding either scenario, you have to pay extra care that you do not corrupt your register contents and that you set up your stack correctly so that when you return from task-switching code you are at the right place on the stack of the incoming task.
Hope this helps.
I see that advantages or running programs simultaeously are that the user can run multiple programs and it offers better CPU usage, can any one give me an example of when it actually saves CPU time? eg busy waiting?
Not sure if I understand right, but when your emacs is waiting for you to type, you save time by scheduling another application while waiting for keyboard inputs.