Re: [SPAM] Re: [PATCH] HACK: Atari ST-RAM allocator using fixed pool of bootmem
On Fri, 4 Jul 2008, Michael Schmitz wrote:
> > > Slightly less hackish implementation of that hack attached. This (on top
> > > of my max_dma_address patch before) does solve the ramdisk related atafb
> > > problems without resorting to artificial RAM limits. Stephen, please try
> > > this patch.
> > I finally tried this patch and it seems to work fine. I know you said
> > it's not ready to be merged, but it fixes a major d-i problem I'm
> > having.
> My major problem with that patch is that it introduces a memory leak because
> memory allocated from the ST-RAM reserve pool cannot be freed. For the
> intended purpose (i.e. framebuffer) this does not matter. If it gets to be a
> problem, ST-RAM memory with the BLOCK_POOL flag set could be put back on the
> corresponding free list. (On alloc, a suitable chunk is looked for on the free
> list, but there's no code to actually put something back on the free list. I'd
> be kind of embarassed to ask for such code to be merged...)
> BTW: The same 'memory leak' is present for memory allocated before mem_init
> was run, so that's really not too serious.
> > The latest d-i images seem to require aranym FastRAM to be 48M which
> > invokes low memory mode. I'd rather not have to go there. :)
> Well, that kind of rules out installing on a TT ever again...
> Did you try whether this patch actually does require the maxdma patch as well?
> I'm unsure about that right now.
> Anyway, the patch seems to be required for ramdisk use, so I better clean it
> up one way or the other. Geert - do we need to be able to free allocated
> ST-RAM? Otherwise, I'd just remove the dead freelist stuff and submit that.
Sorry, I'm a bit lost. Which patch(es) do you mean?
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- email@example.com
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds