[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