Re: [Fwd: Page allocator doubt]

Luciano A. Stertz
2004-11-12T11:37:00Z

Marcelo Tosatti wrote:
> 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).
>

Thanks Dave and Marcelo. You're obviously right. I'll do it.

Luciano

--
Luciano A. Stertz
luciano@tteng.com.br
T&T Engenheiros Associados Ltda
http://www.tteng.com.br
Fone/Fax (51) 3224 8425