[Gllug] Writing my own system call

Christian Smith csmith at thewrongchristian.org.uk
Mon Jun 20 15:48:54 UTC 2011


On Sun, Jun 19, 2011 at 01:55:01AM +0100, James Courtier-Dutton wrote:
> On 15 June 2011 11:49, Adrian McMenamin <adrian at newgolddream.dyndns.info> wrote:
> > I need to know the physical address of memory allocated from the heap in
> > user space (this is for research, not because I am suggesting this is a
> > sensible thing for anyone in the real world to be able to do) - I am
> > researching/confirming phases of memory locality in the kernel.
> >
> > As far as I can see the only way I will be able to do this is to write my
> > own system call handle the return from __pa().
> >
> > But, just to check - anyone know of a simpler way?
> 
> You need to create your own device driver.
> You can then load this as a module. Use code in the module to create a
> file in /dev
> You can then open the file, and do ioctl to it to retrieve the
> information you need.
> Probably only about 20 lines of code.
> 
> Just look in the kernel source for a device driver and modify it to your needs.
> 
> You will need the ioctl call to do this so that the kernel knows the
> context of which user space program is making the ioctl request and
> use this to convert virtual to physical correctly.
> 
> The device driver will only have to support open, ioctl, close  function calls.
> 


This page may be of use:
http://lwn.net/Kernel/LDD3/

The chapter on character drivers and memory mapping might be of most interest.
In the memory mapping chapter, on page 435, there is a function described
to get the struct page entries of a defined user virtual address range
(get_user_pages()) which sounds like what you need. From the array of
struct page pointers, you can get the physical address of each page.

I'm curious, though. What are you actually trying to measure? While a process
certainly shows locality within it's virtual address space, the VM hardware
means that locality is not required in physical memory, and physical pages are
too big to have any effect on the caching of data, which will likely happen in
much smaller chunks (on the order of 32-128 bytes?) The biggest effect of 
page level locality is in NUMA systems, where reading pages from a remote
board can be much slower than a local memory slot.

Anyway, device driver with IOCTL is a much cleaner way than syscall.

Christian
--
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list