On Tue, Sep 13, 2022 at 11:16:19AM +0800, Gary Lin via Grub-devel wrote: > On Tue, Sep 13, 2022 at 01:49:51AM +0800, Zhang Boyang wrote: > > Hi, > > > > This patch should probably fix the slow loading problem introduced by > > 887f98f0db43 (mm: Allow dynamically requesting additional memory > > regions). > > > > Although I'm not against increasing default heap size, simply increasing > > heap size may not fully fix the problem. I think the root cause is disk > > caches are always invalidated when almost every malloc() after default > > heap size is exhausted. > > > Deferring disk cache invalidation may not be a good idea because disk > cache is not mission-critical, so it's reasonable to invalidate the > caches to squeeze more memory blocks. The real question is still about > the default heap size. The memory allocation path is not cheap and it > should be avoided as much as possible. If the first allocated heap can > fulfill the most cases, then users won't be bothered by the performance > drop that much. > I see your point now. Instead of keeping a minimal heap, your patch maximizes the heap to a certain point and then invalidates disk caches to sequeeze the last memory pages. This certainly benefits the performance.
Gary Lin > Gary Lin > > > However, I havn't reproduced the problem, so I haven't tested my patch. > > I would appreciate if someone can test this patch. > > > > Changes in V2: > > Use GRUB_MM_HEAP_GROW constant instead of hardcoding 0x100000. > > Renamed "rsize" to "grow". > > Check "grow" against sanity limits. > > > > Best Regards, > > Zhang Boyang > > > > > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
