Date: Thu, 19 Jul 2018 16:13:01 -0400 From: Mark Johnston <markj@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: freebsd-arch@freebsd.org Subject: Re: early x86 microcode loading Message-ID: <20180719201301.GB57191@raichu> In-Reply-To: <2745.1531523130@critter.freebsd.dk> References: <20180712183116.GB15892@raichu> <50839.1531428749@critter.freebsd.dk> <20180712224631.GF15892@raichu> <2745.1531523130@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 13, 2018 at 11:05:30PM +0000, Poul-Henning Kamp wrote: > -------- > In message <20180712224631.GF15892@raichu>, Mark Johnston writes: > > >I can think of three ways to address this case: > > > >1a) Always load all of the updates as a single file, and select the > > correct update during boot. As I pointed out, this wastes some > > memory (a couple of megabytes currently). On at least amd64 it > > doesn't look very practical to release the pages backing the > > update file back to the VM. That is, I don't think we can easily > > "shed" the preloaded file data once the correct update has been > > selected and saved. > > Then we should fix that problem, rather than build an elaborate > workaround for in each and every subsystem which runs into this. I implemented this in r336505 and plan to use it for the microcode update file. > Isn't this the same issue with the splash-screen for instance ? I didn't look into the splash screen code, but it can be made to give memory back to the system by using preload_delete_name().
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180719201301.GB57191>