Hello, the first patch allows filesystems to have an influence on the read ahead of libblock. The second one uses it in our FAT implementation during reads.
I tested the patches on a SD card attached to an i.MX6ULL based system. To test it I used an empty 16 MB FAT partition. The bdbuf cache in the test application has been 1MB. First I wrote one big file (which should have nearly no fragments, because the partition has been empty before the write) and tested how long it takes to read the entire file. My read speed increased from 2040 kiByte/s to 2070 kiByte/s for the first read of the file (about 1.5 percent faster). For all consecutive reads it increased from about 3230 kiByte/s to 3340 kiByte/s which is 3 to 4 percent faster for all follow up reads. As a second test I first filled the partition with lots of small (about 8000 with only a few bytes per file). Then I removed one random file at a time and filled the space up by attaching data to a big file. I did that for about a third of the files. With that I created a heavily fragmented file. Linux "filefrag" tool tells me that my 5.3 MiB file has 2680 fragments which is about 2kiB per fragment. The read speed for this big fragmented file increased from 2530 kiByte/s to 2920 kiByte/s for the first read (about 15 percent faster). For consecutive reads it increased from 2910 kiByte/s to 3170 kiByte/s which is nearly 9 percent faster. I didn't analyze why the first read is allways a bit slower. Either for the consecutive reads some blocks are still in the cache or some resources are allocated during that time. It's also possible that the SD card has some internal cache that causes this. These results have been reached when optimizing BSP, libbsd and application with -O2. For an unoptimized build (-O0) it was more in the range of 25 percent faster for a fragmented file. If the patch set is OK, I'll create a ticket for it (with the information from this mail) and push it to RTEMS master. Best regards Christian _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
