View the Most Wanted LQ Wiki articles.
Go Back > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Linux - Kernel This forum is for all discussion relating to the Linux kernel.


  Search this Thread
Old 07-07-2010, 11:57 AM   #1
LQ Newbie
Registered: Jul 2010
Posts: 1

Rep: Reputation: 0
open /dev/mem with O_SYNC instead of O_ASYNC


I have a tricky issue.
I have an application doing some graphical operations on some mapped memory. I wrote a kernel module which accesses some hardware features of my microcontroller. These HW-features (also graphics relataed), work on the real physical memory.

Now the use case is as follows:
- my applciation writes something to the mapped memory. Directly after that the HW works on the physical memory. This physical memory is the "root" for my mapped memory. So I expect SW and the HW function to work on the same memory.
So my SW performs an update. Then the HW needs to do something BUT, it must be ensured that the mapped memory has been written back to the physical memory (so that the HW works on the latest data).

Currently my only method to ensure that is to open the memory with O_SYNC and not O_ASYNC. O_ASYNC performs the memory synchronization in the background but this means my HW is not working on the latest data.

Is there a way to force the mapped memory to be written back to the physical memory? I thought msync could help me there, but it's not implemented for ARM-environment. So any idea?

Old 07-09-2010, 04:25 PM   #2
Registered: Feb 2002
Location: Grenoble
Distribution: Debian
Posts: 9,566

Rep: Reputation: 164Reputation: 164
The memory area should be made non-cacheable. You can mark pages this way in the ARM MMU.
Old 06-21-2012, 07:55 AM   #3
LQ Newbie
Registered: Jun 2012
Posts: 2

Rep: Reputation: Disabled
-bump- But that causes a performance penalty

I am dealing with the same issue with a different HW device - a video encoder.

Using non-cached memory causes every single write() to that region to go all the way to the RAM. This is unacceptable for large regions (HD and higher resolutions), as it causes around a 4x performance penalty. So the memory must be cached. Using O_SYNC works but is also a performance penalty as (I think) it does more or less the same.

Currently I am open()-ing /dev/mem and using mmap() with the physical address as the offset. This works ok as long as I dont have to write(). once I do write() I am at the kernel's writeback scheduling's mercy and my HW encoder has no idea if the data is reliable or not.

I tried using msync() as it seems the logical solution, but /dev/mem can't be synced for whatever reason.

Is there any way for the userspace application to force a memory sync on a physical address range "on-demand" and flush all the cached pages to the RAM?

Old 06-21-2012, 08:23 AM   #4
LQ Guru
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 6,870

Rep: Reputation: 2049Reputation: 2049Reputation: 2049Reputation: 2049Reputation: 2049Reputation: 2049Reputation: 2049Reputation: 2049Reputation: 2049Reputation: 2049Reputation: 2049
I frankly would suggest that your kernel module should implement a virtual device for your application to read and write into. Even if "what it actually does" merely involves reading and writing to shared memory, this protocol will provide an explicit method for your driver to remain in-sync with what your app is doing and when it's doing it. Your driver is now "the one who gets the call." So, now, you have your fingers on both the carrying-out of work requests and the issuing of them. It's all now under the same set of code, all of which you have control of. There could be all sorts of possible "race conditions" otherwise, and this conceptual change ought to enable you to quash them all.

I say "virtual device" because that's a generally useful and generally easy-to-digest software handle for any ol' application program to deal with, but of course it's not the only one. And, yeah, maybe the overhead is more than you can afford to incur. So, "it's just a thought," and maybe/maybe-not a good one.

Last edited by sundialsvcs; 06-21-2012 at 08:28 AM.
Old 06-21-2012, 08:41 AM   #5
LQ Newbie
Registered: Jun 2012
Posts: 2

Rep: Reputation: Disabled
Thanks for the quick reply.

Writing my own driver can solve the problem - that I'm sure.

It just seems strange to me that the kernel doesn't give any API to a userspace app to "flush" cached memory to RAM like it does to files. I was hoping that maybe I'm missing something... Am I?



Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Android permission to open("/dev/mem",...) eseitelbach Linux - Software 0 11-04-2009 09:05 AM
Kernels refuses to mmap (open FD) on /dev/mem ( CAP_SYS_RAWIO) DannyGilbert Linux - Kernel 5 08-04-2009 10:30 PM
Startx Permission problems on /dev/null and /dev/mem on freshly compiled Eric_Cartman Linux - Kernel 2 09-09-2007 01:42 AM
How to open /dev/mem in kernl code? cyu021 Linux - Software 0 03-31-2005 12:28 PM
BLFS: XFree86; TDFX(0) Cannot open /dev/mem. And some other related questions SparceMatrix Linux From Scratch 1 06-14-2003 02:38 PM

All times are GMT -5. The time now is 08:57 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration