From: Christoph Hellwig <hch@infradead.org>
To: Jes Sorensen <jes@wildopensource.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [patch] mspec driver for 2.6.12-rc2-mm3
Date: Sun, 24 Apr 2005 11:16:15 +0100 [thread overview]
Message-ID: <20050424101615.GA22393@infradead.org> (raw)
In-Reply-To: <yq08y3bys4e.fsf@jaguar.mkp.net>
> >> int count; /* Number of pages allocated. */ + int type; /* Type of
> >> pages allocated. */ + unsigned long maddr[1]; /* Array of MSPEC
> >> addresses. */
>
> Christoph> dito
>
> The code use the size to calculate, it could be changed either way,
> don't think it's worth making the change.
The current code is obsufcated, see the pages-1 stuff and co.
Please change it.
> >> + /* + * The kernel requires a page structure to be returned upon +
> >> * success, but there are no page structures for low granule pages.
> >> + * remap_page_range() creates the pte for us and we return a + *
> >> bogus page back to the kernel fault handler to keep it happy + *
> >> (the page is freed immediately there). + */
>
> Christoph> Please don't use the ->nopage approach thenm but do
> Christoph> remap_pfn_range beforehand. ->nopage is very nice if the
> Christoph> region is actually backed by normal RAM, but what you're
> Christoph> doing doesn't make much sense.
>
> Thats what I used to think, however you want the node-local setup for
> performance reasons. Otherwise I would have switched to remap_pfn_range.
Then fixup remap_pfn_range (or rather add a new _node variant). The
current code relies on deep magic to work and could be broken by a new
kernel release easily.
> >> +/* + * Walk the EFI memory map to pull out leftover pages in the
> >> lower + * memory regions which do not end up in the regular memory
> >> map and + * stick them into the uncached allocator + */ +static
> >> void __init +mspec_walk_efi_memmap_uc (void)
>
> 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.
That comment doesn't make sense at all to me. exports what to what other
users. And through what way. Please bring this issue up on the ia64
list again. (also please post this patch to linux-ia64, too)
Jes, is it just me or are you trying to chicken out on all the real
problems? :-)
next prev parent reply other threads:[~2005-04-24 10:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-12 9:56 Jes Sorensen
2005-04-12 10:21 ` Andrew Morton
2005-04-12 10:22 ` Andrew Morton
2005-04-12 10:27 ` Andrew Morton
2005-04-12 14:50 ` Jes Sorensen
2005-04-13 20:43 ` Christoph Hellwig
2005-04-22 11:21 ` Jes Sorensen
2005-04-24 10:16 ` Christoph Hellwig [this message]
2005-04-25 10:13 ` Jes Sorensen
2005-04-25 14:32 ` Christoph Hellwig
2005-04-25 14:41 ` efi_memmap_walk_uc, was " Christoph Hellwig
2005-04-25 14:47 ` returning non-ram via ->nopage, " Christoph Hellwig
2005-04-26 22:14 ` Jes Sorensen
2005-04-27 15:53 ` Jeff Garzik
2005-04-27 15:55 ` Christoph Hellwig
2005-04-27 18:03 ` Jes Sorensen
2005-04-27 18:55 ` Russell King
2005-05-03 20:40 ` William Lee Irwin III
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=20050424101615.GA22393@infradead.org \
--to=hch@infradead.org \
--cc=akpm@osdl.org \
--cc=jes@wildopensource.com \
--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
all inboxes | Powered by JetHome®