[coyotos-dev] Fixing the kernel heap size

Trey Boudreau trey at treysoft.com
Thu Dec 20 12:37:11 EST 2007


On Thu, Dec 20, 2007 at 11:14:01AM -0500, Jonathan S. Shapiro wrote:
> 
> On Thu, 2007-12-20 at 06:25 -0500, Godfrey Vassallo wrote:
> > Charles Landau's suggestion to question the "struct Page" object
> > relative to device memory is worth consideration. Is it possible to
> > store a much larger page size in the struct and to compute the tlb
> > data required? At first blush that may be workable for s/w managed
> > tlb's but will present a problem for h/w managed tlb's. 
> 
> This is an interesting point. It's not a problem for h/w managed TLBs
> either. Here are the requirements:
> 
> 1. Page size must be a power of two.
> 2. Page size must be <= basic system page size.
> 3. Whatever page size you choose, that becomes the least unit of
>    sharing.  Hmm. That may not be correct. I need to think about that
>    one.
> 
> So the issue with larger page sizes for devices is mainly that they
> constrain the use of shared mappings to larger units.
> 
> Godfrey, I think you have made an interesting and provocative point
> here.
> 
At Be we used one of the "large/fast segment" translation mappings
available in the PPC and Pentium to map the video memory.  It let us map
the (then) huge 32MB display buffers using a single entry.  As I recall,
it had the restriction that it could only map the PCI memory to a
location a multiple of its size.  I know I've probably forgotten some
critical detail, but I blame that on the decade that has past since I
wrote graphics drivers for them.  In any case, a restriction on mapping
to multiples of the map size doesn't seem prohibitive, even for 1GB
cards (assuming such a card lives in a 64bit environment), especially if
you can safely use one of these large translation entries.

-- Trey


More information about the coyotos-dev mailing list