From: Christoph Hellwig <hch@infradead.org>
To: Jes Sorensen <jes@wildopensource.com>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org
Subject: efi_memmap_walk_uc, was Re: [patch] mspec driver for 2.6.12-rc2-mm3
Date: Mon, 25 Apr 2005 14:41:35 +0000 [thread overview]
Message-ID: <20050425144135.GB9902@infradead.org> (raw)
In-Reply-To: <yq03btftb9u.fsf@jaguar.mkp.net>
On Mon, Apr 25, 2005 at 06:13:01AM -0400, Jes Sorensen wrote:
> Your approach doesn't work. This relies on first-touch to get
> performance, remap_pfn_range_node wouldn't work.
>
> Christoph> I'm pretty sure this was NACKed on the ia64 list, and SGI
> Christoph> was told to do a more generic efi memmap walk.
> >> No the issue back then was that the driver just took the memory
> >> and kept it to itself. The new approach exports it for other users.
>
> Christoph> That comment doesn't make sense at all to me. exports what
> Christoph> to what other users. And through what way. Please bring
> Christoph> this issue up on the ia64 list again. (also please post
> Christoph> this patch to linux-ia64, too)
>
> mspec_alloc_page can be called from anywhere by anyone who wants to
> allocate an uncached page. The old fetchop driver just took the
> uncached memory and kept to itself. Thats what I am talking about!
> Earlier versions of the patch has already been by the ia64 list, we're
> down to details here.
See the thread starting at
http://marc.theaimsgroup.com/?l=linux-ia64&m\x105883467032028&w=2
My reading is that it requests two things:
- not duplicating the EFI memmap walk in a new function but rather
have generic EFI memmap walk replaces the current efi_memmap_walk
- an uncached memory allocator below the driver (not in the driver!).
Your allocator design also doesn't seem to take many of the suggestions
and recommendations in that thread in account.
parent reply other threads:[~2005-04-25 14:41 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <yq03btftb9u.fsf@jaguar.mkp.net>]
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=20050425144135.GB9902@infradead.org \
--to=hch@infradead.org \
--cc=akpm@osdl.org \
--cc=jes@wildopensource.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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