[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