Sponsored Content
Top Forums UNIX for Advanced & Expert Users thread context switches: detection, prevention Post 302177806 by fabulous2 on Sunday 23rd of March 2008 11:35:56 AM
Old 03-23-2008
Quote:
Originally Posted by jim mcnamara
Raise the base priority of the process.

Use realtime processing in sched.h if your system has it. I do not know if java supports this or not.

Thanks for the pointer about sched.h.

According to The Linux Kernel Archives the latest stable version of the Linux kernel is 2.6.24.3. Unfortunately, I was not able to find an online listing for sched.h for that kernel version. If anyone knows of a good source for this stuff lemme know. (Altho maybe it does not matter: while you will get 2.6.24 with, say, ubuntu 8.04 when released, currently you get 2.6.2 with ubuntu 7.10) The closest version to it that I found was linux-2.6.4/include/linux/sched.h

That version has a few occurences of "real", but none seemed to be relevant. Feel free to point out anything that I may have missed.

I have never done any kernel hacking before. If I modify sched.h, would I then have to recompile the kernel and somehow reboot into the new version or something?

Let me ask a general question. Suppose that you have a multi-core CPU. Does a single process (or thread?)--in linus, solaris, windows--get the entire CPU at once, or can multiple processes/threads simultaneously be on the CPU?

I would have thought the latter is true, but when I began thinking about how a context switch is done, which includes saving all the CPU registers, it seems like it might be the case that just a single process/thread should occupy the CPU at once, else it might be difficult/impossible to know which registers belong to what? Or is this a non-issue? I would love to be educated.

Also, is the linux interrupt system responsible for periodic involuntary process contexct switches? According to p.5 of
Chapter 7: Scheduling
there is the claim that
Quote:
An interrupt occurs every k clock ticks, thus causing the hardware clock's con-troller to execute the logical equivalent of an yield() to invoke the interrupt
handler. The interrupt handler invokes the scheduler to reschedule the CPU.
How often do interrupts in linux occur? Is there any way to disable this, or at least prevent my hot thread from being context switched out of its core when an interrupt occurs?
 

4 More Discussions You Might Find Interesting

1. Programming

Signal Handling and Context Switches

Hi guys, this is my first posting, so at first hi to everyone! ;) I have a problem with ucontext_t in connection with signal handling. I want to simulate a preemptive scheduler. I am using the iTimer with ITIMER_PROF, to schedule the interrupts. You find the code below: #include <stdio.h>... (18 Replies)
Discussion started by: XComp
18 Replies

2. Cybersecurity

Anyone knows any prevention against identity theft?

I have recently been victimized by the theft of my credit card. But, due to favorable situations I could prevent it from being miss-used and was able to make thins go in the right way.Anyways , I would like to know that if there any services which keeps your financial information safe and make you... (4 Replies)
Discussion started by: levi
4 Replies

3. Programming

Parallel Processing Detection and Program Return Value Detection

Hey, for the purpose of a research project I need to know if a specific type of parallel processing is being utilized by any user-run programs. Is there a way to detect whether a program either returns a value to another program at the end of execution, or just utilizes any form of parallel... (4 Replies)
Discussion started by: azar.zorn
4 Replies

4. Shell Programming and Scripting

Questions related to if in awk context and if without awk context

I wrote this code, questions follow #! /bin/bash -f # Purpose - to show how if syntax is used within an awk clear; ls -l; echo "This will print out the first two columns of the inputted file in this directory"; echo "Enter filename found in this directory"; read input; ... (11 Replies)
Discussion started by: Seth
11 Replies
MI_SWITCH(9)						   BSD Kernel Developer's Manual					      MI_SWITCH(9)

NAME
mi_switch, cpu_switch, cpu_throw -- switch to another thread context SYNOPSIS
#include <sys/param.h> #include <sys/proc.h> void mi_switch(void); void cpu_switch(void); void cpu_throw(void); DESCRIPTION
The mi_switch() function implements the machine independent prelude to a thread context switch. It is called from only a few distinguished places in the kernel code as a result of the principle of non-preemptable kernel mode execution. The various major uses of mi_switch can be enumerated as follows: 1. From within a function such as cv_wait(9), mtx_lock(9), or tsleep(9) when the current thread voluntarily relinquishes the CPU to wait for some resource or lock to become available. 2. After handling a trap (e.g. a system call, device interrupt) when the kernel prepares a return to user-mode execution. This case is typically handled by machine dependent trap-handling code after detection of a change in the signal disposition of the current process, or when a higher priority thread might be available to run. The latter event is communicated by the machine independent scheduling routines by calling the machine defined need_resched(). 3. In the signal handling code (see issignal(9)) if a signal is delivered that causes a process to stop. 4. When a thread dies in thread_exit(9) and control of the processor can be passed to the next runnable thread. 5. In thread_suspend_check(9) where a thread needs to stop execution due to the suspension state of the process as a whole. mi_switch() records the amount of time the current thread has been running in the process structures and checks this value against the CPU time limits allocated to the process (see getrlimit(2)). Exceeding the soft limit results in a SIGXCPU signal to be posted to the process, while exceeding the hard limit will cause a SIGKILL. If the thread is still in the TDS_RUNNING state, mi_switch() will put it back onto the run queue, assuming that it will want to run again soon. If it is in one of the other states and KSE threading is enabled, the associated KSE will be made available to any higher priority threads from the same group, to allow them to be scheduled next. After these administrative tasks are done, mi_switch() hands over control to the machine dependent routine cpu_switch(), which will perform the actual thread context switch. cpu_switch() first saves the context of the current thread. Next, it calls choosethread() to determine which thread to run next. Finally, it reads in the saved context of the new thread and starts to execute the new thread. cpu_throw() is similar to cpu_switch() except that it does not save the context of the old thread. This function is useful when the kernel does not have an old thread context to save, such as when CPUs other than the boot CPU perform their first task switch, or when the kernel does not care about the state of the old thread, such as in thread_exit() when the kernel terminates the current thread and switches into a new thread. To protect the runqueue(9), all of these functions must be called with the sched_lock mutex held. SEE ALSO
cv_wait(9), issignal(9), mutex(9), runqueue(9), tsleep(9), wakeup(9) BSD
November 24, 1996 BSD
All times are GMT -4. The time now is 11:44 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy