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

[Christian MAUDERER]

Ping.

I would like to commit the patch set (with changes as requested by 
Gedare and a small bugfix). That is:

- Rename read_ahead_transfers_with_size to read_ahead_peeks.
- Spelling: blocks_till_end_of_disk -> blocks_until_end_of_disk
- Make logic in rtems_bdbuf_read_ahead_task simpler to read.
- Catch peeks of zero length in rtems_bdbuf_peek (small bugfix)

Does someone want to see a v2 for these or can I commit directly?

Am 29.01.21 um 14:07 schrieb Christian MAUDERER:
> 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/