Archive | Interrupts RSS feed for this section

The Tortuous rode to extending the joys of extending Physical Memory Ranges and Page Sizes

By on August 3, 2012 in Huge TLBs, Interrupts, Linux Kernel Memory Management, Linux kernel preemption, Memory Management, Process Scheduling, Processor Throughputs, TLB Management, Uncategorized, x86 Protection Mechanisms

My dear Brethren and Fellow travellers in the land x86 and the Linux Kernel, it is time to come clean on all modes that extend x86 page sizes and physical memory addressing.

So here we go Ka Boom Ka Beem: In 32-bit non-PAE mode, PSE and PSE36 (AKA PSE40), whereby PSE36/40 is a cheap way to get the extended memory addressing for 64GB/1TB, 4K/4M Paging that we created in PSE (Really!) with 32-bit PGDs and PTEs.

In 32-bit PAE mode, the architecture is 32-bit, but the PDPTEs, PDEs and PTEs extend to 64-bit, thereby extending Page sizes to 4K/2M (if PTE is not used), and memory addressing to 52-bits (4PB).

And lastly, but not leastly, we have IA-32E mode (true blue 64-bit architecture), with 48-bit linear addressing, 4K/2M/1G (if PDEs and PTEs are both not used) page sizes, 4PB of Memory addressing, and 64-bit PDPTEs, PDEs and PTEs.

John, did I get it all, and right also, this time ? DID you get the Cigar too ? Haaah ?

We all … must admit to an acute case of x86-itis, so the next post onwards, time to switch gears.  We will start looking next at the various implications to the Kernel of some of these x86-isms for which we have espoused eloquence in this and prior posts.

I will also note that we do do a good job of explaining these concepts in some of our training sessions, this feedback measured by course evaluations, and client (some of which are ISPs) feedbacks also.

I do hope everyone enjoyed this post. Thanks again

Comments { 0 }

Give me another jiffy, only a bit later

By on January 20, 2012 in Interrupts, Kernel Threads, Linux Kernel, Linux kernel preemption

Given the description below, jiffies + 10*HZ means (now + 10 Seconds). And jiffies * 1000 would mean the elapsed time in milliseconds etc.

An example of usage in the Linux Kernel would be in the drivers for XD, where, jiffies + 8*HZ later (as initialized in the member element expires of static struct timer_list) a timer interrupt handler is programmed to execute.

The “watchdog handler” xd_watchdog, in this particular instance, wakes up a sleeping process.

Needless to say, all appropriate caveats emptor apply. Appropriate Processes need to have been sleeping, Timers must have been declared and initialized etc etc

I will blog on this at length later. Please subscribe to our mail list for automated updates on new blog entries.

I explain this specific Linux Kernel concept and more in my classes ( Advanced Linux Kernel Programming @UCSC-Extension, and also in other classes that I teach independently). As always, Feedback, Questions and Comments are appreciated and will be responded to.

Thanks

Comments { 0 }

Linux Kernel: Give me a Jiffy

By on January 20, 2012 in critical code sections, Interrupts, Jiffies, Linux Kernel, Timers

The jiffies variable is a counter that stores the number of elapsed ticks since the system was started

It is increased by one when a timer interrupt occurs—that is, on every processor tick
i.e. at HZ rate. HZ itself is configured globally.

The Kernel makes generous use of this variable. An example would be to “time” timeouts, “budget” Interrupt Back-Half handlers’ usage of Processors etc to prevent “Hogging”.

The xtime variable derives its information from the jiffies variable and stores the current time and date; it is a structure of type timespec having two fields:

tv_sec: Stores the number of seconds that have elapsed since midnight of January 1, 1970 (UTC)
tv_nsec: Stores the number of nanoseconds that have elapsed within the last second (its value ranges between 0 and 999,999,999)

We also need to blog on back-half handlers. Used in a variety of locations where the non-critical component of Interrupt handling is “deferred”, IO, Packet reception, Transmission etc.

Comments { 0 }