Le Wed, Mar 2, 2016 à 4:46 AM, Andrei Borzenkov <arvidj...@gmail.com> a écrit :
> 02.03.2016 03:22, Vladimir 'phcoder' Serbinenko пишет: > > Is there any way this patch reclaims unused memory in case of partial > cache > > eviction? > > Not yet, I wanted to make sure base looks sane first. Are there any > cases of partial eviction besides blocklist write? > > I mean that if you read directly 1M, then you invalidate 255 x 4K, then you really have only 4K of cache left but you still use 1M of RAM. This creates additional memory pressure. Good thing is that grub_malloc will invalidate whole cache and reclaim memory when it's unabkle to find any other spot but it still increases memory fragmentation as grub_malloc prefers squeezing before reclaiming memory. > > If not it could potentially water lots of memory. One thing you > > need to consider is that initrd for Solaris can easily be 60% of total > RAM > > (300 MiB on 512MiB machine) What if requested read is bigger than risk > > cache size? > > > > Not sure I parse it; but yes, it puts more stress on cache by requiring > unfragmented memory. If we follow this route we need to gracefully fall > back to cache element size. > > Problem that in this case caller already has 300M of RAM in buffer it passed and you can't allocate another 300M as machine simply doesn't have so much RAM. What's the cost of core size of your approach? What's speed benefit between your approach and just fixing read_small like Leif proposes? > Do we have any reasonable chance to separate aligned and non-aligned > memory pools? > > How would you allocate 60% of RAM in single chunk in this arrangement? > _______________________________________________ > 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
