Date: Sat, 29 Jun 2013 19:21:13 +0200 From: Olivier Houchard <cognet@ci0.org> To: Alan Cox <alc@rice.edu> Cc: "arm@freebsd.org" <arm@freebsd.org>, Jeff Roberson <jroberson@jroberson.net> Subject: Re: generic_bs_map() Message-ID: <20130629172113.GA90854@ci0.org> In-Reply-To: <51CEED6A.9090802@rice.edu> References: <51CEED6A.9090802@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 29, 2013 at 09:21:30AM -0500, Alan Cox wrote: > Jeff and I have been looking at the various kmem_alloc() calls > throughout the kernel, and when we came to generic_bs_map() on arm, I > was a bit puzzled. In short, I believe that generic_bs_map() should be > calling kmem_alloc_nofault() instead of kmem_alloc(). It appears to me > that generic_bs_map() only wants a virtual address range from kmem_*, > which is what kmem_alloc_nofault() does. In contrast, kmem_alloc() also > allocates and maps physical memory at the returned address range. In > the case of generic_bs_map(), allocating and mapping physical memory is > pointless because generic_bs_map() overwrites those mappings with its > own. So, the physical pages allocated by kmem_alloc() are wasted. > > Neither Jeff nor I have arm hardware to verify this change. Could > someone here please try it out? > > Thanks, > Alan > Hmm you have a point, I don't know how we ended up using kmem_alloc() there, when we rightfully use kmem_alloc_nofault() in pmap_mapdev(). I'll fix this tomorrow if nobody beats me at it. Regards, Olivier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130629172113.GA90854>