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

Reply via email to