This is related to
Primary motivation for my investigation was to verify what performance gain can result from using eSRAM available (kind of) on Quark, using Galileo board (gen 1) and Linux BSP (v. 1.0.2). The results are... well... unexpected. With some additional effort maybe it would be possible to make eSRAM usable, but more insight into what's really going on.
I've run two memory performance tests, one in the kernel and one in user space for various "kinds" of memory. The test consisted of performing, in a tight loop, a sequence of memory reads from a 512kB memory area. After each read the address is incremented by 32 and finally wrapped back. (The step is 32 since I'm trying to cancel cache influence and thought first that the cache line size is 32B. It is actually 16B for Quark, but there is no fault anyway.)
In user space three memory areas are tested:
dram --- allocated by the test application with malloc()
rmem --- kmalloc()'ed by kernel driver and mmap()'ed by the application
esram --- kmalloc()'ed and overlayed with eSRAM by kernel driver and mmap()'ed by the application
In the driver two memory areas are tested:
rmem --- kmalloc()'ed by driver
esram --- kmalloc()'ed and overlayed with eSRAM by driver
The results are as follows:
Number of reads: 1015808 (~1M)
rmem 104918 104103
esram 62750 61854
Number of reads: 10010624 (~10M)
rmem 1025651 1024575
esram 609470 608786
It looks like the memory allocated in user space is _much_ faster than that allocated by kernel. I must still try to decode from which physical memory block dram comes (need to decode /proc/PID/pagemap). Kernel got memory from
00100000-0efdefff : System RAM
(excerpt from /proc/iomem).
So finally: the question is if there is someone who understands this behaviour?
Any link to Galileo physical memory map?
Is it possible to gain anything from eSRAM over the users space (and preferably in user space)?