[PATCH rtems 0/2] Add Peek Support to libblock and use in dosfs

Christian MAUDERER christian.mauderer at embedded-brains.de
Fri Jan 29 13:07:15 UTC 2021


Any changes except the ones requested by Gedare?

Am 22.01.21 um 14:24 schrieb Christian Mauderer:
> 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
> 
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/


More information about the devel mailing list