From: Magnus Damm <magnus.damm@gmail.com>
To: Nigel Cunningham <ncunningham@cyclades.com>
Cc: linux-mm <linux-mm@kvack.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Dynamically allocated pageflags
Date: Thu, 9 Feb 2006 16:00:47 +0900 [thread overview]
Message-ID: <aec7e5c30602082300i6257606csdc005e6a442bfec5@mail.gmail.com> (raw)
In-Reply-To: <200602022111.32930.ncunningham@cyclades.com>
Hi Nigel,
On 2/2/06, Nigel Cunningham <ncunningham@cyclades.com> wrote:
> Hi everyone.
>
> This is my latest revision of the dynamically allocated pageflags patch.
>
> The patch is useful for kernel space applications that sometimes need to flag
> pages for some purpose, but don't otherwise need the retain the state. A prime
> example is suspend-to-disk, which needs to flag pages as unsaveable, allocated
> by suspend-to-disk and the like while it is working, but doesn't need to
> retain any of this state between cycles.
>
> Since the last revision, I have switched to using per-zone bitmaps within each
> bitmap.
>
> I know that I could still add hotplug memory support. Is there anything else
> missing?
I like the idea of the patch, but the code looks a bit too complicated
IMO. What is wrong with using vmalloc() to allocate a virtual
contiguous range of 0-order pages (one bit per page), and then use the
functions in linux/bitmap.h...? Or maybe I'm misunderstanding.
A system that has 2 GB RAM and 4 KB pages would use 64 KB per bitmap
(one bitmap per node), which is not so bad memory wise if you plan to
use all bits.
OTOH, if your plan is to use a single bit here and there, and leave
most of the bits unused then some kind of tree is probably better.
Or does the kernel already implement some kind of data structure that
never consumes _that_ much more space than a bitmap when fully used,
and saves a lot of memory when just sparsely populated?
/ magnus
--
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:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-02-09 7:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-02 11:11 Nigel Cunningham
2006-02-02 13:31 ` Andi Kleen
2006-02-02 16:47 ` Dave Hansen
2006-02-08 23:43 ` Nigel Cunningham
2006-02-09 7:00 ` Magnus Damm [this message]
2006-02-09 7:08 ` Nigel Cunningham
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=aec7e5c30602082300i6257606csdc005e6a442bfec5@mail.gmail.com \
--to=magnus.damm@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ncunningham@cyclades.com \
/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