October 2012 - kernelnewbies@kernelnewbies.org

yet another tutorial: where does all that stuff in /proc/interrupts come from?
by Robert P. J. Day Oct. 24, 2012

Oct. 24, 2012

dashed off in about an hour: http://www.crashcourse.ca/wiki/index.php/Proc_interrupts eventually, all these tutorials will be reorganized and will allow reader comments so you can give feedback and ask questions. enjoy. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

About effective resolution of cpu execution clocks
by Miguel Telleria de Esteban Oct. 24, 2012

Oct. 24, 2012

Dear all, I resend this question that I posted yesterday in the Linux Real-Time mailing list but received no answers maybe due to its "newbie status". http://marc.info/?l=linux-rt-users&m=135099100016609&w=2 let me rephrase-it for a generic not necessary real-time aware audience: The question concerns the per-process CPU usage statistics maintained by the kernel. As far as I can tell, the only places where this usage counter is stored are in the utime and stime fields of task_struct. http://lxr.linux.no/#linux+v3.6.3/include/linux/sched.h#L1362 (line 1362) I have observed that these fields are of type "cputime_t" which seems to be defined as an unsigned long and therefore contain 32bits (at least in a 32bit architecture such as x86). http://lxr.linux.no/linux+v3.6.3/include/asm-generic/cputime.h#L7 These fields utime and stime are used as accumulators of time usage in the implementation of POSIX CPU-usage clocks and timers. http://lxr.linux.no/#linux+v3.6.3/kernel/posix-cpu-timers.c A typical use-case of this functionality is measuring the CPU time consumed by a thread. In real-time systems this information can be used for further actions such as changing its priority, sending a signal or whatever. Here is an example using NPTL from libc: clockid_t clock; struct timespec before_ts, after_ts, interval; pthread_getcpuclockid( pthread_self(), &clock ); clock_gettime(clock, &before_ts); ... do your things here clock_gettime(clock, &after_ts); interval = timespec_substract(after_ts, before_ts); In this code the time is stored in a struct timespec which is composed of 2 32-bit longs obtaining both a resolution of nanoseconds and a expand of years. On the other side 32bit integers such as utime and stime cannot provide both a high resolution and high time span. And according to the man page of proc, when these fields are output from /proc/<pid>/stat they give the value in jiffies (1/CONFIG_HZ sg, i.e. 4 millisec in most kernel configs). The way clock_gettime works, when linked to a process CPU clock is by keeping a counter of CPU usage updated by the scheduler on every preemption action + using hardware facilities to measure the latest time period. I assume that Linux, specially since the merge of high resolution timers in 2.6.21, benefits now from the latest "hardware facilities for time management" gaining resolutions of micro and nanoseconds, as reported by clock_getres(). With this background in mind I repeat the same questions that I asked in the linux-rt mailing list: * What is the effective resolution of two invocations of clock_gettime() on the same running thread for a long period involving several CPU preemptions? * Are there other fields apart from stime and utime with the sufficient precision to maintain a CPU usage count? * Does the PREEMPT_RT branch improve this resolution somehow? Thanks in advance for your time. Cheers, Miguel Telleria -- ----------------------------------------------------------------------- Miguel TELLERIA DE ESTEBAN Grupo de computadores y tiempo real telleriam ENSAIMADA unican.es Dept. Electrónica y Computadores (change "ENSAIMADA" for @) Universidad de Cantabria http://www.ctr.unican.es Tel trabajo: +34 942 201477 -----------------------------------------------------------------------

1 0

Rdefined GDT_ENTRY_DEFAULT_USER_DS
by Fan Yang Oct. 23, 2012

Oct. 23, 2012

Hi all: When I search the macro __USER_DS, I find that the GDT_ENTRY_DEFAULT_USER_DS has been redefined two times in the file arch/x86/asm/segment.h. Is that to compatible with the old kernel version? Thanks Fan

1 0

looking for simple kernel source examples of, well, everything
by Robert P. J. Day Oct. 23, 2012

Oct. 23, 2012

while writing/updating a pile of kernel courseware over the next couple of months, i'm interested in bolstering everything in the courseware with actual examples ripped from the source code, so students can see all of the concepts in action. for example, to show how to use seq_file to write a trivial read-only proc file, i always point at fs/proc/version.c: ===== start ===== #include <linux/fs.h> #include <linux/init.h> #include <linux/kernel.h> #include <linux/proc_fs.h> #include <linux/seq_file.h> #include <linux/utsname.h> static int version_proc_show(struct seq_file *m, void *v) { seq_printf(m, linux_proc_banner, utsname()->sysname, utsname()->release, utsname()->version); return 0; } static int version_proc_open(struct inode *inode, struct file *file) { return single_open(file, version_proc_show, NULL); } static const struct file_operations version_proc_fops = { .open = version_proc_open, .read = seq_read, .llseek = seq_lseek, .release = single_release, }; static int __init proc_version_init(void) { proc_create("version", 0, NULL, &version_proc_fops); return 0; } module_init(proc_version_init); ===== end ===== not surprisingly, students can *immediately* see how to use that as the basis to write their own. if i want to show a seq_file that is actually being used sequentially, i typically like to show how /proc/devices is implemented (see fs/proc/devices.c). anyway, you get the idea. it's a wide open invitation -- i'm just trying to collect really elegant examples from the kernel source code to explain various concepts. if you have any favourites, by all means, post them and i'll start collecting them somewhere public. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

Regarding the Kernel Configuration Options
by supratim chakraborty Oct. 23, 2012

Oct. 23, 2012

I was looking for some resources on the explanation on all (or even some for that matter) kernel configuration options that come up in the pre- compilation phase (make menuconfig ) . I looked over but couldnt find such a guide Can somebody point me in the right direction ? -Supratim Chakraborty (techturning.in) (about.me/borax12 <http://about.me/borax12>) (facebook.com/techturning)

3 2

online, possible and disabled cpus
by Robert P. J. Day Oct. 23, 2012

Oct. 23, 2012

at this point, i'm trying to rationalize why i'm seeing this in the output of dmesg: [ 0.000000] smpboot: Allowing 16 CPUs, 8 hotplug CPUs on my quad-core asus laptop, as in -- where is that "16" coming from? if i list /proc/cpuinfo, i see 8 processors, so i'm just trying to understand what "16" represents, so let's read backwards. first, that line above seems to be printed from arch/x86/kernel/smpboot.c: pr_info("Allowing %d CPUs, %d hotplug CPUs\n", possible, max_t(int, possible - num_processors, 0)); so, *apparently*, by that time, the boot process has established that there are 16 "possible" processors, but only 8 actual ones. but who decided there were 16 "possible" processors? just above that in the same file, we have: if (setup_possible_cpus == -1) { possible = num_processors; #ifdef CONFIG_HOTPLUG_CPU if (setup_max_cpus) possible += disabled_cpus; #else if (possible > i) possible = i; #endif } else possible = setup_possible_cpus; total_cpus = max_t(int, possible, num_processors + disabled_cpus); whoa, so it appears that we get "possible" cpus from adding the number of *actual* cpus to the number of "disabled" cpus. but what is a "disabled" cpu, and who decides how many there are? last thing i notice is this earlier in my dmesg output: [ 0.000000] ACPI: PM-Timer IO Port: 0x408 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x03] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x05] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x07] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x09] lapic_id[0x08] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x09] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0a] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0b] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0c] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0d] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0e] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x10] lapic_id[0x0f] disabled) which certainly seems to be related to all of this -- 8 enabled and 8 disabled. so i'm going to keep following this back, unless someone wants to break it to me what is going on. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

3 11

Fwd: creating own syscall on 2.6.37.3 and getting error on compilaton...
by Filipe Rinaldi Oct. 23, 2012

Oct. 23, 2012

On 22 October 2012 13:48, Tristan <rgonzale(a)darkterminal.net> wrote: > How can you tell that cpu_rq() is a private macro? Because there is no header for it? Be as specific as you can, I'd like to completely understand what the concept. I'll try the current macro. Thanks Filipe. > > -Tristan Hi Tristan, By private I mean it was declared inside sched.c so only code from sched.c can access it. Note also cpu_rq() uses "runqueues" which is also private (declared static) to sched.c. Cheers, -Filipe

1 0

New member queries..
by shampavman.cg Oct. 23, 2012

Oct. 23, 2012

Hi Guys, I'm new to linux kernel development (only a few hrs old i may say). I've been working with the solaris kernel from the past year and now would like to concentrate on linux as well. "My area of expertise is Filesystems". Here are a few things i would like to know from you guys. 1.) I've looked at the bugzilla pages, how do i choose a bite sized bug to start with? (Is there such a concept at all?) 2.) I looked at kernelJanitors page as well hoping to find info but nothing much there . Can anyone help me get started? Thanks Shampavman

4 3

/proc/cpuinfo versus /proc/softirqs: how to properly count CPUs?
by Robert P. J. Day Oct. 22, 2012

Oct. 22, 2012

poking around under /proc on my quad-core asus laptop and just noticed that while /proc/cpuinfo (properly) lists my 8 processors, /proc/softirqs instead lists 16, with the last 8 having values of all zeroes (not surprisingly). with the middle columns snipped for brevity, my /proc/softirqs shows: CPU0 CPU1 ... CPU13 CPU14 CPU15 HI: 0 0 ... 0 0 0 TIMER: 1018887 45313 ... 0 0 0 NET_TX: 1182 1813 ... 0 0 0 NET_RX: 991 719 ... 0 0 0 BLOCK: 44559 13 ... 0 0 0 BLOCK_IOPOLL: 0 0 ... 0 0 0 TASKLET: 41582 419 ... 0 0 0 SCHED: 76438 28658 ... 0 0 0 HRTIMER: 738 709 ... 0 0 0 RCU: 136797 82392 ... 0 0 0 with all of the zero values from CPU8-CPU15. so the obvious question is -- why? why the difference in the way those two proc files count the "number" of CPUs on my system? for /proc/cpuinfo, the logic is in arch/x86/kernel/cpu/proc.c, and the way the seq_file is implemented: static void *c_start(struct seq_file *m, loff_t *pos) { *pos = cpumask_next(*pos - 1, cpu_online_mask); if ((*pos) < nr_cpu_ids) return &cpu_data(*pos); return NULL; } so that loop clearly iterates through the "online" CPUs, which would appear to be the correct loop criteria. the code for softirqs, however, is in fs/proc/softirqs.c, and is much simpler: static int show_softirqs(struct seq_file *p, void *v) { int i, j; seq_puts(p, " "); for_each_possible_cpu(i) seq_printf(p, "CPU%-8d", i); seq_putc(p, '\n'); for (i = 0; i < NR_SOFTIRQS; i++) { seq_printf(p, "%12s:", softirq_to_name[i]); for_each_possible_cpu(j) seq_printf(p, " %10u", kstat_softirqs_cpu(i, j)); seq_putc(p, '\n'); } return 0; } note that that code uses the macro "for_each_possible_cpu()" rather than examining only *online* CPUs. in dmesg, i see the lines: [ 0.000000] smpboot: Allowing 16 CPUs, 8 hotplug CPUs [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:16 nr_node_ids:1 and the code for all this counting is in arch/x86/kernel/smpboot.c, which you can check out for yourself, but this brings me back to the basic question -- why is the code for softirqs iterating through all *possible* CPUs (in my case, apparently, 16), when i have only 8 *online* CPUs? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 2

some weird redundancy with a workqueue?
by Robert P. J. Day Oct. 22, 2012

Oct. 22, 2012

is there something i'm missing about the following snippet of code in drivers/acpi/osl.c? if (queue == kacpi_hotplug_wq) INIT_WORK(&dpc->work, acpi_os_execute_deferred); else if (queue == kacpi_notify_wq) INIT_WORK(&dpc->work, acpi_os_execute_deferred); else INIT_WORK(&dpc->work, acpi_os_execute_deferred); does anyone else find that code a bit ... odd? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

3 2