linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Luciano A. Stertz" <luciano@tteng.com.br>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: linux-mm <linux-mm@kvack.org>
Subject: Re: [Fwd: Page allocator doubt]
Date: Thu, 11 Nov 2004 18:22:51 -0200	[thread overview]
Message-ID: <4193CA1B.1090409@tteng.com.br> (raw)
In-Reply-To: <1100201816.7883.22.camel@localhost>

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...

> 
> -- Dave
> 
> --
> 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>
> 

--
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>

  reply	other threads:[~2004-11-11 20:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-11 14:37 Luciano A. Stertz
2004-11-11 19:10 ` Dave Hansen
2004-11-11 19:27   ` Luciano A. Stertz
2004-11-11 19:36     ` Dave Hansen
2004-11-11 20:22       ` Luciano A. Stertz [this message]
2004-11-11 20:34         ` Dave Hansen
2004-11-11 21:21         ` Marcelo Tosatti
2004-11-12 11:37           ` Luciano A. Stertz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4193CA1B.1090409@tteng.com.br \
    --to=luciano@tteng.com.br \
    --cc=haveblue@us.ibm.com \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox