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>
next prev parent 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