Re: [Fwd: Page allocator doubt]

[Marcelo Tosatti <marcelo.tosatti@cyclades.com>]

On Thu, Nov 11, 2004 at 06:22:51PM -0200, Luciano A. Stertz wrote:
> Dave Hansen wrote:
> >On Thu, 2004-11-11 at 11:27, Luciano A. Stertz wrote:
> >
> >>	But... are they allocated to me, even with page_count zeroed? Do I 
> >>	need to do get_page on the them? Sorry if it's a too lame question, but I 
> >>still didn't understand and found no place to read about this.
> >
> >
> >Do you see anywhere in the page allocator where it does a loop like
> >yours?
> >
> >        for (i = 1; i< 1<<order; i++)
> >		get_page(page + i);
> 	Actually this loop isn't mine. It's part of the page allocator, but 
> it's only executed on systems without a MMU.
> 
> >When you do a multi-order allocation, the first page represents the
> >whole group and they're treated as a whole.  As you've noticed, breaking
> >them up requires a little work.
> >
> >Why don't you post all of the code that you're using so that we can tell
> >what you're doing?  There might be a better way.  Drivers probably
> >shouldn't be putting stuff in the page cache all by themselves.  
> 	Unhappily I can't post any code yet, but I'll try to give an insight 
> 	of what we're trying to do.
> 	It's not a driver. We're doing an implementation to allow the kernel 
> 	to execute compressed files, decompressing pages on demand.
> 	These files will usually be compressed in small blocks, typically 
> 	4kb. But if they got compressed in blocks bigger then a page (say 8kb 
> blocks on a 4kb page system), the kernel will have more than one 
> decompressed page each time a block have to be decompressed; and I'd like 
> to add them both to the page cache.
> 	So, seems I would have to break multi-order allocated pages. Is this 
> possible / viable? If not, maybe I'll have to work only with small 
> blocks, but I wouldn't like to...

Why do you need the pages to be physically contiguous?

I dont see any reason for that requirement - you can use discontiguous physical
pages which are virtually contiguous (so your decompression code wont need to 
care about non adjacent pieces of memory).
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>