0

I would like to get the physical address of Linux "jiffies" variable so that I can read it by just reading the contents of this memory address.

limp
  • 889
  • 2
  • 14
  • 22

6 Answers6

4

From kernel-mode code (e.g. a loadable kernel module) you need to include the <linux/jiffies.h> header file. It contains the definition of the jiffies variable:

extern unsigned long volatile __jiffy_data jiffies;

However, it also contains this warning:

/*
 * The 64-bit value is not atomic - you MUST NOT read it
 * without sampling the sequence number in xtime_lock.
 * get_jiffies_64() will do this for you as appropriate.
 */

I.e. you should not access this variable directly. It's a 64-bit variable and accesses to it are not atomic on 32-bit systems, hence the get_jiffies_64() function from the same header file. On 64-bit systems that function is a very simple inline function that returns the value of the jiffies variable.

From userspace code, on the other hand, you cannot access kernel memory at all.

thkala
  • 84,049
  • 23
  • 157
  • 201
  • 1
    To clarify: `jiffies_64` should not be accessed directly. `jiffies`, however, is safe to access directly on all architectures (you will only get the low 32 bits on 32 bit architectures, which is usually good enough). [See LDD3 chapter 7.] – Eric Seppanen Apr 11 '11 at 03:37
  • @Eric Seppanen: It never even occurred to me to mention the 32-bit value. Been burnt a few times with it and 3rd-party kernel drivers of questionable quality - I saw the 32-bit value roll over on some of my systems and I had to deal with the aftermath... – thkala Apr 11 '11 at 08:17
  • Jiffies rollover shouldn't be a problem as long as you write correct code. That's why `time_after()` and `time_before()` exist-- to handle the rollover gracefully. – Eric Seppanen Apr 11 '11 at 14:45
2

This is not directly related to your question but might still be relevant. I maintain a small project (devmem-rw) here: http://code.google.com/p/device-memory-readwrite/

It's quite useful to driver/kernel developers/testers; it lets one setup to be able to read/write any valid memory location- this could be RAM (user/kernel space), memory-mapped register locations, shared memory regions, etc.

Pl see the wiki area of the project (specifically, http://code.google.com/p/device-memory-readwrite/wiki/UsageWithExamples).

More relevant to your question, I use this project to demo a few use cases, one of them being repeated reads on the 'jiffies' value. Seeing that it changes proves the point..

From http://code.google.com/p/device-memory-readwrite/wiki/UsageWithExamples :

"... Eg. 2: Reading the value of 'jiffies' on an x86 PC The 'vm_img' kernel module mentioned earlier, also shows us the location of the 'jiffies_64' kernel global variable (which holds the current jiffies value); in the above run, it's kernel location turns out to be 0xc07c7a40. So:

# ./rdmem 0xc07c7a40 ; sleep 1; ./rdmem 0xc07c7a40 ; sleep 1; ./rdmem 0xc07c7a40
        +0          +4          +8          +c            0   4   8   c   
+0000   00 1a bc 20                                       ...             
        +0          +4          +8          +c            0   4   8   c   
+0000   00 1a bd 23                                       ...#            
        +0          +4          +8          +c            0   4   8   c   
+0000   00 1a be 1f                                       ....            
#

We can see how it's updated...(in fact, CONFIG_HZ=250 on this system, and some + factor is expected as well...). ... "

Pl see the project page for details. It's been found to be quite useful for driver developers- for eg they can probe/change register values without writing code :) Do give it a spin!

kaiwan
  • 2,114
  • 1
  • 18
  • 23
2

For kernel code, use the functions defined in include/linux/jiffies.h. (get_jiffies_64 for example).

Kernel command using Linux system calls illustrates syscall handling in Linux with a userspace syscall that reads jiffies. Could be what you're after.

Linux obtain current of jiffies since reboot over at superuser also has some information you could be interested in.

Converting jiffies to milli seconds is also something to keep in mind.

Community
  • 1
  • 1
Mat
  • 202,337
  • 40
  • 393
  • 406
0

If you have the sources installed, 

locate jiffies

schould reveal the .c and .h files, as in:

/usr/src/linux-headers-$(uname -r)/include/linux/jiffies.h
user unknown
  • 35,537
  • 11
  • 75
  • 121
0

When you reference jiffies from kernel code, that's exactly what happens. What do you think needs improving in normal usage? If you need the address just use &jiffies.

Eric Seppanen
  • 5,923
  • 30
  • 24
  • Though, apparently you are not supposed to reference that variable directly. It's a 64-bit variable and accesses to it are not atomic on 32-bit systems, hence the `get_jiffies_64()` function. – thkala Apr 09 '11 at 14:55
  • If you're fine with only receiving a 32-bit value, you can directly use `jiffies` on a 32-bit machine. The upper 64 bits are there if you need them (and that's what `get_jiffies_64()` is for, but it's rare that you would need the full value. – Eric Seppanen Apr 11 '11 at 03:33
0

I think what you want is to access jiffies values from userspace.

You can write a small module that expose the jiffies variable to a proc file.

Rumple Stiltskin
  • 9,597
  • 1
  • 20
  • 25