Tag Info

Hot answers tagged

14

Here's a high-level view of the low-level processing. I'm describing a simple typical architecture, real architectures can be more complex or differ in ways that don't matter at this level of detail. When an interrupt occurs, the processor looks if interrupts are masked. If they are, nothing happens until they are unmasked. When interrupts become unmasked, ...


7

This is covered in chapter 10 of Linux Device Drivers, 3rd edition, by Corbet et al. It is available for free online, or you may toss some shekels O'Reilly's way for dead tree or ebook forms. The part relevant to your question begins on page 278 in the first link. For what it's worth, here is my attempt to paraphrase those three pages, plus other bits I've ...


7

A hardware interrupt in not really part of CPU multitasking, but may drive it. Hardware interrupts are issued by hardware devices like disk, network cards, keyboards, clocks, etc. Each device or set of devices will have its own IRQ (Interrupt ReQuest) line. Based on the IRQ the CPU will dispatch the request to the appropriate hardware driver. (Hardware ...


7

All modern operating systems support multitasking. This means that the system is able to execute multiple processes at the same time; either in pseudo-parallel (when only one CPU is available) or nowadays with multi-core CPUs being common in parallel (one task/core). Let's take the simpler case of only one CPU being available. This means that if you ...


5

Gilles already described the general case of an interrupt, the following applies specifically to Linux 2.6 on an Intel architecture (part of this is also based on Intel's specifications). An interrupt is an event that changes the sequence of instructions executed by the processor. There are two different kinds of interrupts: Synchronous interrupt ...


5

System calls, messaging passing (as described in the Wikipedia article), and interrupts are all things that cause a context switch or a switch from user to kernel mode. As you likely know: kernel mode: programs have a flat or real view of memory, and programs can read/write freely to all memory and all hardware devices directly without restriction. user ...


4

Interrupts are handled by the operating system, threads (or processes, for that matter) aren't even aware of them. In the scenario you paint: Your thread issues a read() system call; the kernel gets the request, realizes that the thread won't do anything until data arrives (blocking call), so the thread is blocked. Kernel allocates space for buffers (if ...


4

System calls can be interrupted through the use of signals, such as SIGINT (generated by CTRL+C), SIGHUP, etc. You can only interrupt them by interacting with the system calls through a PID, however when using Unix signals and the kill command. rt_patch & system calls @Alan asked the following follow-up question: Is the possibility to interrupt ...


3

Message passing is a higher level concept of one process sending a message to another. It is implemented by a system ( kernel ) call, asking the kernel to pass the message to the other process. System calls ask the kernel to perform various services for the process. They are implemented by a software interrupt / system trap, which causes the cpu to save ...


3

The Linux kernel is reentrant (like all UNIX ones), which simply means that multiple processes can be executed by the CPU. He doesn't have to wait till a disk access read is handled by the deadly slow HDD controller, the CPU can process some other stuff until the disk access is finished (which itself will trigger an interrupt if so). Generally, an interrupt ...


2

As of today, you can mostly forget about the SA_INTERRUPT flag. In between 2.6.18 and 2.6.24 it was just a migration helper for the new IRQF_DISABLED flag. 2.6.24 removed all SA_* flags and replaced them with IRQF_* flags. 2.6.35 marked this "new" flag as deprecated. If you have a kernel before 2.6.18, you'll probably won't use it (see Justin's answer). ...


2

There is a good write up here: Older versions of the Linux kernel took great pains to distinguish between "fast" and "slow" interrupts. Fast interrupts were those that could be handled very quickly, whereas handling slow interrupts took significantly longer. Slow interrupts could be sufficiently demanding of the processor, and it was worthwhile to ...


2

For example the 82093AA IO-APIC has I/O redirection table registers (IOREDTBL) which have a writeable bit specifying the trigger mode (which can be level or edge sensitive). These registers seem to be reflected by struct IO_APIC_route_entry in the kernel source. Digging a bit through the 2.6.18 kernel source, one comes across a function ...


2

From the kernel documentation: nointremap [X86-64, Intel-IOMMU] Do not enable interrupt remapping. [Deprecated - use intremap=off] For information about IOMMU, have a look at the Wikipedia page.


2

I don't think it's possible to receive a signal on a file change. However inotify, https://en.wikipedia.org/wiki/Inotify, should allow you to write a program that receives events as a file changes. This site has a good write up about inotify: http://www.win.tue.nl/~aeb/linux/lk/lk-12.html. It also has a sample example that monitors events in the current ...


2

As with any performance tuning there are no absolute rules. Due to the nature of it, there are a few rules that you can make with sufficient qualification but only a few. So bear that in mind. How you should control for hardware interrupts really depends on how your workload behaves For your question, you also have to control where the interrupts are sent. ...


1

Seems like a fairly easy issue to resolve, I would just run top or htop and see what process is consuming resources during one of these boundaries between the 15 minute windows where you're seeing the issue crop up. You can also use a tool like nethogs to identify which process is consuming the most network resources. Example To monitor my wireless ...


1

Linux provides two mechanism for monitoring file system events; dnotify and inotify. The older of the two, dnotify, was introduced in kernel version 2.4.0. It allows applications to register to receive notifications on changes in a directory via the fcntl() interface. The notifications themselves are delivered via signals. The dnotify mechanism is limited ...


1

How fast can you type? ;-) Both USB and network are easy ways to generate interrupts: if you have a USB audio or video device, recording might to the trick use ping -f or a TCP or UDP flood tool, e.g. (tcpflood If you have the equipment and a suitable kernel, a square-wave generator hooked up to one of the GPIO ports should work too. You might also be ...


1

Of course interrupts can interrupt system calls, unless an appropriate spinlock is taken, or interrupts are disabled in some other way: spin_lock_irq*() gets a spinlock and disables hardware interrupts (and, consequently, also software interrupt and tasklet processing). spin_lock_bh() gets a spinlock and disables software interrupt and tasklet processing. ...


1

The timer ISR doesn't call schedule() directly. It ends up calling update_process_times() so the scheduler process accounting information is up to date. The scheduler is eventually called when returning to userspace. If the kernel is preemptive, it is also called when returning from the timer interrupt to kernelspace. As an example, imagine a process A ...


1

The systemtap stuff is supposed to let you drill down into the kernel, and lately also applications, for tracing, troubleshooting, and debugging. Haven't used it myself. High interrupt traffic for high network traffic might be due to less-than-bright network card or driver, perhaps a higer-end card gives better results. The kernel's handling of networking ...


1

When a driver requests a shared IRQ, it passes a pointer to the kernel to a reference to a device specific structure within the driver's memory space. According to LDD3: Whenever two or more drivers are sharing an interrupt line and the hardware interrupts the processor on that line, the kernel invokes every handler registered for that interrupt, ...


1

I think you are mixing what you are trying to ask. There are hardware interrupts generated by events on various devices. But you can definitely look at the question here: http://stackoverflow.com/questions/1245809/what-is-int-21h About DOS Interrupt 21h which was used to handle certain Software Only functions like program exit.


1

Here is some hardcore trick: Control-Z it will suspend your process and it'll return you the job ID of that process Then: kill -9 %1 (replace 1 with your job ID). Note: Percentage is mandatory!, otherwise you'll kill your init process which means you will kill the kernel and the whole system will crash (so don't put the space in between :)


1

The problem lied somewhere in the keyboard preferences under gnome-keyboard-properties. Reset to defaults under layout fixed everything. I was able to then re-do the same settings I had before. The good thing is, it works now. The bad thing, I could not catch the specific reason why it behaved this way.


1

You're barking up the wrong tree. Having the interrupts go to both CPUs would make performance worse, not better. For one thing, it would mean the software decoder would constantly be interrupted. For another, it would mean the interrupt code would be less likely to be hot in cache. There are many other reasons this would make things worse.


1

Chapter 6 of "Linux Kernel Development" by Robert Love explains it, as do these free web resources: Linux Kernel Module Development Guide linuxdriver.co.il Linux Device Drivers Basically, the top half's job is to run, store any state needed, arrange for the bottom half to be called, then return as quickly as possible. The bottom half does most of the ...


1

Nonpreemptible means that those handlers cannot be interrupted by another interrupt. For non-preemtible handlers, reentrance is a non issue since you cannot interrupt them in the first place. As to what the kernel does, just check wag's answer, I can't comment like he does on this topic.


1

First of all participants involved in interrupt handling are peripheral hardware devices, interrupt controller, CPU, operating system kernel and drivers. Peripheral hardware devices are responsible for interrupt generation. They assert interrupt request lines when they want attention from operating system kernel. These signals are multiplexed by interrupt ...



Only top voted, non community-wiki answers of a minimum length are eligible