On Thu, 2023-02-09 at 15:13 +0100, Daniel Kiper wrote: > > Is that really necessary? Note that this is also used for legacy MBR/BIOS > > systems and I faintly remember places using that, which may do so in a fixed > > way, so I advise to check it well if you really intend to change it. > > I concur. I think I would do this only for UEFI systems first. If at all > we need to increase this value. How often the GRUB reads the same files > from the disk? Did you notice faster loads/boots when you increase the > disk cache size?
It depends :-) But yes, we have empirical evidence. This is indeed mostly an issue on UEFI systems where we tend to load a few large files since all the modules are contained within the pre-built grub image. Anyways, i'll play around and see if I can come up with something that works. Just increasing the size of cache entries actually has a negative impact in things like filesystem metadata for example. And caching large files doesn't make much sense. So I wonder if we can pass some hints or open-time flags to indicate that some files (kernel, initrd) shouldn't bother with caching, along with making get_block() be able to return a number of contiguous blocks, allowing large file reads to avoid any bouncing, caching, and enable larger chunks. At this point, it's something I'm putting on my backburner todo list, I might get to it in the future... Cheers, Ben. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel