I think I found a better solution now.
Opening /dev/mem was done by
info->mem_fd = open("/dev/mem", O_RDWR);
before, i changed it to
info->mem_fd = open("/dev/mem", O_RDWR | O_SYNC);
Now it works with the speed I expected and I don't have to drop the cache.
I'm not really sure if I should also use the O_DIRECT flag, but when doing
so (and defining #define _GNU_SOURCE (see
http://www.titov.net/2006/01/02/using-o_largefile-or-o_direct-on-linux/)),
I get a segfault when reading from the mapped buffer, I don't know why.
With only O_SYNC it works as it should.
What do you think about this solution?
Am Sonntag, 6. Oktober 2013 16:44:59 UTC+2 schrieb Nils Zottmann:
>
> Okay, my problem seems to be this:
> http://en.wikipedia.org/wiki/Direct_memory_access#Cache_coherency
>
> Is there a way to do this without programming kernel-level code? I've
> never done this before and don't really know what to do exactly.
> I found the option to drop the cache by writing a "1"
> to /proc/sys/vm/drop_caches. I used this is my program with this few lines
> of code:
>
> FILE * fd;
> fd = open("/proc/sys/vm/drop_caches", O_WRONLY);
> write(fd, "1", sizeof(char));
> close(fd);
>
> It works most of the time, but sometimes I have to write the "1" a few
> more times until the cache is really flushed. Perhaps this is only a
> problem with another cache when writing to this file.
>
> I have some more questions now:
>
> This is a workaround, but I think no good solution. Is there any nicer way
> to drop the cache in C?
> Could I get performance problems at another point if I drop the cache too
> often (about every sec. later)?
> Is there a possibility to drop only the cache for my memory section? Or to
> disable caching for this part of memory?
> Is there a function like memcpy which is able to read directly from the
> memory without looking in the cache?
>
>
> Thank you for the help!
>
> Nils
>
>
> Am Freitag, 4. Oktober 2013 23:00:34 UTC+2 schrieb Charles Steinkuehler:
>>
>> On 10/4/2013 12:13 PM, Nils Zottmann wrote:
>> > Has anyone an explanation for this behaviour? Perhaps it is a problem
>> with
>> > some kind of cache, how could I get around this? I'd like to implement
>> a
>> > ring buffer but it would have to be very large if it has to take data
>> of
>> > several seconds.
>>
>> You are encountering caching effects on the ARM side. The proper way to
>> deal with this is to set the memory flags appropriately in the MMU,
>> typically with kernel-level code that's setting up to do DMA. The PRU
>> in this use case basically looks like a "smart" peripheral that can
>> modify the contents of memory directly. That is the same as any other
>> DMA enabled I/O device, and requires the same care with handling of the
>> memory regions.
>>
>> --
>> Charles Steinkuehler
>> [email protected]
>>
>>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
