Dog days of summer …

So weeks go by and you’re probably thinking

What is up with those send receive reply guys? They haven’t posted anything in weeks!

True … it has been a few weeks, but we haven’t been idle.  There are exciting things a brew at QNX during the summer heat … air conditioning being one of them that tends to only make sporadic appearances unfortunately.

One of the more interesting features that is has worked its way into the Neutrino kernel for the next release (slated for the not too distant future) is going to be the ability to report out the mapping of physical memory of a system to virtual addresses used by individual processes. 

“But we live in a virtual address world“,  you say “why would we want a physical map of a systems memory?”

That was certainly my first impression.  Particularly with the fact that you can get a complete virtual address mapping for a process using the /proc filesystem and the appropriate devctl() and the entries for <sys/procfs.h> and <sys/debug.h>, you should be able to paint a fairly complete memory story all using virtual address information.

Turns out that that isn’t quite the case.  You can get close, but there are still some missing details when it comes to how particular shared libraries and executables are mapped within other mapped areas (for example using execute in place within secondary image file systems).  Getting access to the physical address allows you to resolve that ambiguity quite nicely.

Also, while I mentioned in the article on fragmentation (yes … we will get back to that issue =;-) that the OS nominally hands out memory uniformly in ~4K chunks, it does have the ability to fragment over time.  In general this isn’t a problem since the MMU for the processor provides the mapping giving you virtual continuity over fragmented physical memory.

Unless you need (or want) physically contiguous memory.  This can lead to improved performance in some device drivers that can leverage DMA and direct IO data transfers.  It is also a requirement by some tooling like the instrumented kernel, that arranges its data buffers as one contiguous ring.

The interface for extracting this additional memory information will be through the /proc interface and is a multi-stage procedure, but the fact that the information is now available is great news.  

Now all we need is a tool to showcase this new information … nothing like writing a handy utility to help beat the heat!



3 comments so far

  1. hp on

    great news!
    don’t forget to integrate this into qconn and the IDE (you know: give’em your little finger …).
    Heat? I need a dinghy to beat the water …

  2. Kevin on

    My sales guy won’t tell me exactly but says there is a bunch of things coming soon. Looking forward to it…

  3. Mario on

    “What is up with those send receive reply guys?”

    This a free service and anyone that complains should be hang ;-)

    I’m happy for any information you guys give what ever rate your giving it ;-)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: