[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] efika memory issues

From: Robert Millan
Subject: Re: [PATCH] efika memory issues
Date: Tue, 31 Jul 2007 21:42:32 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

On Tue, Jul 31, 2007 at 10:55:09AM -0500, Hollis Blanchard wrote:
> On 7/31/07, Robert Millan <address@hidden> wrote:
> > On Mon, Jul 30, 2007 at 05:35:28PM -0500, Hollis Blanchard wrote:
> > > >         When GRUB_IEEE1275_FLAG_EFIKA_SECRET_AVAILABLE_REGION was set,
> > > >         release hardcoded 0x4000:0xffc000 region.
> > >
> > > Hmm, does this actually work? Since GRUB itself falls within that
> > > regions, the grub_ieee1275_release() call will mark all the memory
> > > that the GRUB kernel and modules occupy as free, which means they will
> > > be clobbered by heap usage.
> >
> > Didn't think of this.. (by chance it worked here, though).  How about using
> > max(_end,0x4000) instead of 0x4000 ?
> >
> > (and adjusting region length not to overflow 0x1000000)
> That won't quite work because the modules are loaded in the area
> immediately following the kernel. However, because they are added in a
> post-processing step, we don't know their end address at link time.
> I think the simplest solution will be to allocate Efika's heap high,
> as we talked about earlier. If the first "available" region is above
> 4MB, just reserve 4MB and don't worry about where it is. In general we
> should try to keep 4MB free, but at the end of the day it's Efika's
> fault and probably won't be a big deal for them anyways.

Ok, let's do that.  But what do we do if the first available region is
just a few kBs below 4MB?  Or if it's just too small?  I think we need to
determine what is the minimum heap size we want to accept, such that the
ability to keep 4MB free still compensates having a small heap.

Any suggestion?

Robert Millan

My spam trap is address@hidden  Note: this address is only intended
for spam harvesters.  Writing to it will get you added to my black list.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]