On Tue, Dec 10, 2019 at 04:43:54PM +0100, Hubert Feurstein wrote: > Hi Sascha, > > Am Di., 10. Dez. 2019 um 16:10 Uhr schrieb Sascha Hauer > <s.hauer@xxxxxxxxxxxxxx>: > [...] > > Well the commit message says it: > > | commit b6fef20c1215c6ef0004f6af4a9c4b77af51dc43 > > | Author: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> > > | Date: Thu Mar 29 13:49:45 2018 +0200 > > | > > | block: Adjust cache sizes > > | > > | Use four times more cache entries and divide the memory for each entry > > | by four. This lowers the linear read throughput somewhat but increases > > | the access speed for filesystems. > Yes, I know. I've read the commit message. But this patch even costs me ~200ms > in boottime (loading kernel and dts from ext4 root partition). > > [...] > > We could adjust RW_BUF_SIZE (used by copy_file as buffer size) to a full > > chunk size (16KiB). Does this give you back some lost performance? > No, changing RW_BUF_SIZE did not help. And I also see why :-/ block_op_write() works around block sizes (512bytes), not around chunk sizes. This means we always read before we write. This could probably be optimized somehow, but this would only speed up the write case you described in your initial mail. It seems what you are more interested in is the read performance. We could make the number of chunks and the chunk size configurable during runtime. This is less than ideal, but at least we could get a better performance with manageable effort. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
