From: Christoph Lameter <cl@linux-foundation.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
linux-arch@vger.kernel.org
Subject: Re: [patch] mm: rewrite vmap layer
Date: Wed, 20 Aug 2008 12:05:36 -0500 [thread overview]
Message-ID: <48AC4EE0.4050603@linux-foundation.org> (raw)
In-Reply-To: <20080820165947.GA19656@wotan.suse.de>
Nick Piggin wrote:
> On Wed, Aug 20, 2008 at 11:50:09AM -0500, Christoph Lameter wrote:
>> Nick Piggin wrote:
>>
>>> Indeed that would be a good use for it if this general fallback mechanism
>>> were to be merged.
>> Want me to rebase my virtualizable compound patchset on top of your vmap changes?
>
> Is there much clash between them? Or just the fact that you'll have to
> use vm_map_ram/vm_unmap_ram?
There is not much of a clash. If you would make vmap/unmap atomic then there
is barely any overlap at all and the patchset becomes much smaller and even
the initial version of it can support in interrupt alloc / free.
> I probably wouldn't be able to find time to look at that patchset again
> for a while... but anyway, I've been running the vmap rewrite for quite
> a while on several different systems and workloads without problems, so
> it should be stable enough to test out. And the APIs should not change.
Yes I think this is good stuff. Hopefully I will get enough time to check it
out in detail.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Lameter <cl@linux-foundation.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
linux-arch@vger.kernel.org
Subject: Re: [patch] mm: rewrite vmap layer
Date: Wed, 20 Aug 2008 12:05:36 -0500 [thread overview]
Message-ID: <48AC4EE0.4050603@linux-foundation.org> (raw)
In-Reply-To: <20080820165947.GA19656@wotan.suse.de>
Nick Piggin wrote:
> On Wed, Aug 20, 2008 at 11:50:09AM -0500, Christoph Lameter wrote:
>> Nick Piggin wrote:
>>
>>> Indeed that would be a good use for it if this general fallback mechanism
>>> were to be merged.
>> Want me to rebase my virtualizable compound patchset on top of your vmap changes?
>
> Is there much clash between them? Or just the fact that you'll have to
> use vm_map_ram/vm_unmap_ram?
There is not much of a clash. If you would make vmap/unmap atomic then there
is barely any overlap at all and the patchset becomes much smaller and even
the initial version of it can support in interrupt alloc / free.
> I probably wouldn't be able to find time to look at that patchset again
> for a while... but anyway, I've been running the vmap rewrite for quite
> a while on several different systems and workloads without problems, so
> it should be stable enough to test out. And the APIs should not change.
Yes I think this is good stuff. Hopefully I will get enough time to check it
out in detail.
--
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:[~2008-08-20 17:05 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-18 13:32 [patch] mm: rewrite vmap layer Nick Piggin
2008-08-18 13:32 ` Nick Piggin
2008-08-19 0:24 ` Andrew Morton
2008-08-19 0:24 ` Andrew Morton
2008-08-19 7:37 ` Russell King
2008-08-19 7:37 ` Russell King
2008-08-19 10:39 ` Nick Piggin
2008-08-19 10:39 ` Nick Piggin
2008-08-20 3:32 ` Kyle McMartin
2008-08-20 3:32 ` Kyle McMartin
2008-08-19 10:02 ` Nick Piggin
2008-08-19 10:02 ` Nick Piggin
2008-08-19 14:42 ` Christoph Lameter
2008-08-19 14:42 ` Christoph Lameter
2008-08-20 9:02 ` Nick Piggin
2008-08-20 9:02 ` Nick Piggin
2008-08-20 14:03 ` Christoph Lameter
2008-08-20 14:03 ` Christoph Lameter
2008-08-20 16:22 ` Nick Piggin
2008-08-20 16:22 ` Nick Piggin
2008-08-20 16:50 ` Christoph Lameter
2008-08-20 16:50 ` Christoph Lameter
2008-08-20 16:59 ` Nick Piggin
2008-08-20 16:59 ` Nick Piggin
2008-08-20 17:05 ` Christoph Lameter [this message]
2008-08-20 17:05 ` Christoph Lameter
2008-08-20 17:48 ` Nick Piggin
2008-08-20 17:48 ` Nick Piggin
2008-08-21 7:19 ` Johannes Weiner
2008-08-21 7:19 ` Johannes Weiner
2008-08-21 13:13 ` Christoph Lameter
2008-08-21 13:13 ` Christoph Lameter
2008-09-05 3:06 ` Andrew Morton
2008-09-05 3:06 ` Andrew Morton
2008-09-07 12:06 ` Nick Piggin
2008-09-07 12:06 ` Nick Piggin
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=48AC4EE0.4050603@linux-foundation.org \
--to=cl@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.