I'm writing a system which process network packets on SMP (centos 6.4).
I'm using cpu isolation and running a single ktrhead on some of the cores, if I don't release the cpu once on a while by calling schedule() the system get watch dog, I've tried to move to real time priority and release the cpu for specific amount of time, for example 50 jiffies every 450 jiffes, but it get stuck.
my question, is jiffies updated by softirq kthread? preventing from jiffies to increment if I don't release the cpu?
Thanks
jiffies is incremented when timer interrupt is hit. Timer interrupt is hit by system timer. It is not updated by softirq kthread.
In x86, system timer is implemented via programmable interrupt timer (PIT). PPC implements it via decrementer.
From the description of your thread, it seems your thread is locking up the cpu, hence watchdog hit is expected based on its timeout. In most systems, jiffies is 10ms; however you can check its value by checking value of HZ: HZ value will give number of timer interrupts in a second, hence there are HZ jiffies in a second.
In your case, whenever you release the CPU, watchdog thread gets a chance to run and check the current jiffies and then it compares with the jiffies value stored when it was last run: if it finds the difference greater than or equal to watchdog timeout, it hits and resets the system if configured.
Related
Trying to understand, how and where grace period in an RCU is initialized. Is there a static declaration somewhere in Linux Kernel to define the grace period, or are there some other complex ways to do this, for example as per this small snippet:
for_each_online_cpu(cpu)
run_on(cpu);
grace period is total time taken to run the current thread on all the CPUs and after this total time has elapsed all the readers are done their critical sections ?
hello i was like to ask how i can make rdtsc more stable ? i read it as main system timer clock
1 i read it in first core by reading ZwSetInformationThread(ThreadAffinityMask)
2 create its own thread so its read correctly in first core PsCreateSystemThread
3 increase irql to dispatch_level then lower it in PASSIVE_LEVEL It allows other important tasks to run in between cause its not good run on dispatch_level all the time
is there more ways to make rdtsc not overflow?
I want to change the scheduler tcik time(The amount of time CPU spends on each process).
Initially I checked about jiffies, jiffies variable represents the no.of timer ticks from the boot. CONFIG_HZ in the configuration file represents no.of timer ticks per second, please correct me if this is not correct.
The CONFIG_HZ value is same as scheduler tick time ? if it is different then please guide me where I can change the scheduler tick time.
Yes CONFIG_HZ defines the number of ticks in one second.
Basically scheduler is invoked every 1/CONFIG_HZ second for taking waking, task sleeping, balance load.
scheduler_tick -> This function gets called every 1/CONFIG_HZ second.
CONFIG_HZ defined in Kconfig and its value is set using .config which can be modified using menuconfig.
Global Variable jiffies holds the number of ticks that have occurred since the system has booted.
I d like to clarify about terms.
Jiffies is strictly speaking a measure of time.
Like we have hours , minutes, seconds exactly the same thing
is jiffy. And only after that it happens so that kernel works
with time via jiffy units.
It happens so that scheduler is launched every jiffy (roughly
speaking). to get more details i suggest to look at "linux kernel development" book. - https://github.com/eeeyes/My-Lib-Books/blob/master/Linux%20Kernel%20Development%2C%203rd%20Edition.pdf
A certain computer system runs in a multi-programming environment using a non-preemptive
algorithm. In this system, two processes A and B are stored in the process queue,
and A has a higher priority than B. The table below shows estimated execution time for each
process; for example, process A uses CPU, I/O, and then CPU sequentially for 30, 60, and 30
milliseconds respectively. Which of the following is the estimated time in milliseconds
to complete both A and B? Here, the multi-processing overhead of OS is negligibly
small. In addition, both CPU and I/O operations can be executed concurrently, but I/O
operations for A and B cannot be performed in parallel.
UNIT : millisecond
CPU I/O CPU
A_______________30___________________60_________________30
B_______________45___________________45__________________--
Please help me.. i need to explain this in front of the class tomorrow but i cant seem get the idea of it...
A has the highest priority, but since the system is non-preemptive, this is only a tiebreaker when both processes need a resource at the same time.
At t=0, A gets the CPU for 30 ms, B waits as it needs the CPU.
At t=30, A releases the CPU, B gets the CPU for 45 ms, while A gets the I/O for 60 ms.
At t=75, the CPU sits idle as B is waiting for A to finish I/O, and A is not ready to use the CPU.
At t=90, A releases I/O and gets the CPU for another 30 ms, while B gets the I/O for 45 ms.
At t=120, A releases the CPU and is finished.
At t=135, B releases I/O and is finished.
It takes the longest path:
Non-preemptive multitasking or cooperative multitasking means that the process is kind of sharing a.e. the CPU time. In the worst case they use the worst time to achieve theire task.
CPU:
B = 45 is longer than A=30
45 +
I/O
A = 60 and B = 45
45 + 60
CPU again:
A = 30
45 + 60 + 30 = 135
i will explain in brief and please elaborate for your classroom discussion:
For your answer :135
when Process A waits for the I/O task,the CPU time will be given to Process B. so the complete time for process A and B would be
Process A (CPU )+ Process A I/O and Process B CPU + Process B I/O
30+60+45 = 135 ms
When I write a simple application, running for 10 minutes, that starts 10 threads once (pthreads), each sleeping for 1 ms in a loop (not doing anything else) the CPU is used ca. 44% (top reports that). It is a ARM9 CPU with 450 MHz, Linux 2.6.37 is used as OS. There is no other program running, it tried out different kernel configs (Dynamic Ticks, Soft/Hard IRQ, High Resolution Timer, ..., ..., ...), different priorities (up to 99) but the numbers stay the same. /usr/bin/time -v shows ca. 5'200'000 voluntary context switches and ca. 3 minutes are spent in Kernel space. Sleepin in each thread for ca. 5 ms and the CPU utilization goes down to ca. 9% which is IMO still crazy (40'500'000 cycles to safe some registers). clock_nanosleep was used for sleeping (CLOCK_REALTIME/CLOCK_MONOTONIC did not change anything).
I'm aware that a full context switch is expensive on ARM9 because caches have to be cleared. But a simple thread switch, or switch to the OS shouldn't be that expensive IMHO (address space remains the same, no cache/TLB flushing required). Is this common or should I try to find the bottleneck in the kernel?
You're busily waking up and going back to sleep at 100uS intervals -- 10 threads, 1ms, that's 100uS on average. And keep in mind that you have two context switches for each of those 100uS intervals, so you have a context switch every 50uS on average, or 20,000 times per second.
Perhaps that's the answer you're looking for?