On Sun, Jul 22, 2012 at 12:46:13PM -0700, Linus Torvalds wrote: > On Sun, Jul 22, 2012 at 5:58 AM, Borislav Petkov <b...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
