Re: [RFC] firmware load: defer request_firmware during early boot and resume

[Borislav Petkov <bp@amd64.org>]

On Sun, Jul 22, 2012 at 12:46:13PM -0700, Linus Torvalds wrote:
> On Sun, Jul 22, 2012 at 5:58 AM, Borislav Petkov <bp@alien8.de> wrote:
> >
> > Question: is there any other reason
> >
> >   [besides maybe embedded people who care about each single Kb of memory
> >    on the system]
> >
> > why we don't make this cache/uncache firmware thing *implicit*? That is,
> > load it once at driver open time and keep it in memory during the whole
> > driver's lifetime. And this all taken care of by the driver core, btw.
> 
> So some firmware is a *lot* more than "a few kB". We're talking
> hundreds of kB, sometimes more.

Ok.

> And to make matters worse, we keep it in memory with vmalloc(), which
> is a limited resource on 32-bit systems. So it can actually be worse
> than just the memory use itself.

Ok, a follow-up: why do we use vmalloc space for firmware, actually?
Because it can be a lot more than a few KB as you say above and a normal
kmalloc allocation could fail in such a case?

Becase I recently converted the AMD microcode driver to use a normal
get_zeroed_page page and got rid of all the vmalloc allocations it did
and it is still working :).

What I'm saying is, we probably could take care of the vmalloc issue by
allocating firmware memory early enough so that we can always succeed.
Oh, I see one problem here - the driver could be loaded very late in
the system lifetime and we could be having fragmented physical memory
so that kmalloc does actually fail. In such cases, we can fallback to
vmalloc I guess.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551