LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Password
Linux - Kernel This forum is for all discussion relating to the Linux kernel.

Notices

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

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


Hello,

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?

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

Rep: Reputation: 148Reputation: 148
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
yaronlev
LQ Newbie
 
Registered: Jun 2012
Posts: 2

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

Hi,
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?



Thanks,
Y.
 
Old 06-21-2012, 08:23 AM   #4
sundialsvcs
Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 5,378

Rep: Reputation: 1108Reputation: 1108Reputation: 1108Reputation: 1108Reputation: 1108Reputation: 1108Reputation: 1108Reputation: 1108Reputation: 1108
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
yaronlev
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?

Thanks,
Y.
 
  


Reply


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 2.6.22.1 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 11:44 PM.

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