From: "Martin J. Bligh" <mbligh@aracnet.com>
To: William Lee Irwin III <wli@holomorphy.com>,
Rik van Riel <riel@redhat.com>
Cc: Jack Steiner <steiner@sgi.com>, Anton Blanchard <anton@samba.org>,
Jes Sorensen <jes@trained-monkey.org>,
Alexander Viro <viro@math.psu.edu>, Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, jbarnes@sgi.com
Subject: Re: hash table sizes
Date: Tue, 25 Nov 2003 21:14:32 -0800 [thread overview]
Message-ID: <1590000.1069823671@[10.10.2.4]> (raw)
In-Reply-To: <20031126035953.GF8039@holomorphy.com>
> Speaking of which, no one's bothered fixing the X crashes on i386
> discontigmem. Untested patch below.
>
>
> -- wli
>
>
> diff -prauN linux-2.6.0-test10/include/asm-i386/mmzone.h pfn_valid-2.6.0-test10/include/asm-i386/mmzone.h
> --- linux-2.6.0-test10/include/asm-i386/mmzone.h 2003-11-23 17:31:56.000000000 -0800
> +++ pfn_valid-2.6.0-test10/include/asm-i386/mmzone.h 2003-11-25 19:54:31.000000000 -0800
> @@ -85,13 +85,19 @@ extern struct pglist_data *node_data[];
> })
> #define pmd_page(pmd) (pfn_to_page(pmd_val(pmd) >> PAGE_SHIFT))
> /*
> - * pfn_valid should be made as fast as possible, and the current definition
> - * is valid for machines that are NUMA, but still contiguous, which is what
> - * is currently supported. A more generalised, but slower definition would
> - * be something like this - mbligh:
> - * ( pfn_to_pgdat(pfn) && ((pfn) < node_end_pfn(pfn_to_nid(pfn))) )
> + * pfn_valid must absolutely be correct, regardless of speed concerns.
> */
> -#define pfn_valid(pfn) ((pfn) < num_physpages)
> +#define pfn_valid(pfn) \
> +({ \
> + unsigned long __pfn__ = pfn; \
> + u8 __nid__ = pfn_to_nid(__pfn__); \
> + pg_data_t *__pgdat__; \
> + __pgdat__ = __nid__ < MAX_NUMNODES ? NODE_DATA(__nid__) : NULL; \
> + __pgdat__ && \
> + __pfn__ >= __pgdat__->node_start_pfn && \
> + __pfn__ - __pgdat__->node_start_pfn \
> + < __pgdat__->node_spanned_pages; \
> +})
>
> /*
> * generic node memory support, the following assumptions apply:
Would it not be rather more readable as something along the lines of:
static inline int pfn_valid (int pfn) {
int nid = pfn_to_nid(pfn);
pg_data_t *pgdat;
if (nid >= MAX_NUMNODES)
return 0; /* node invalid */
pgdat = NODE_DATA(nid);
if (!pgdat)
return 0; /* pgdat invalid */
if (pfn < pgdat->node_start_pfn)
return 0; /* before start of node */
if (pfn - pgdat->node_start_pfn >= pgdat->node_spanned_pages)
return 0; /* past end of node */
return 1;
}
However, I'm curious as to why this crashes X, as I don't see how this
code change makes a difference in practice. I didn't think we had any i386
NUMA with memory holes between nodes at the moment, though perhaps the x440
does.
M.
PS. No, I haven't tested my rephrasing of your patch either.
next prev parent reply other threads:[~2003-11-26 7:27 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-25 13:35 hash table sizes Jes Sorensen
2003-11-25 13:42 ` William Lee Irwin III
2003-11-25 13:54 ` Jes Sorensen
2003-11-25 16:25 ` Thomas Schlichter
2003-11-25 17:52 ` Antonio Vargas
2003-11-25 17:54 ` William Lee Irwin III
2003-11-25 20:48 ` Jack Steiner
2003-11-25 21:07 ` Andrew Morton
2003-11-25 21:14 ` Jesse Barnes
2003-11-25 21:24 ` Andrew Morton
2003-11-26 2:14 ` David S. Miller
2003-11-26 5:27 ` Matt Mackall
2003-11-28 14:15 ` Jes Sorensen
2003-11-28 14:52 ` Jack Steiner
2003-11-28 16:22 ` Jes Sorensen
2003-11-28 19:35 ` Jack Steiner
2003-11-28 21:18 ` Jörn Engel
2003-12-01 9:46 ` Jes Sorensen
2003-12-01 21:06 ` Anton Blanchard
2003-12-01 22:57 ` Martin J. Bligh
2003-11-25 21:16 ` Anton Blanchard
2003-11-25 23:11 ` Jack Steiner
2003-11-26 3:39 ` Rik van Riel
2003-11-26 3:59 ` William Lee Irwin III
2003-11-26 4:25 ` Andrew Morton
2003-11-26 4:23 ` William Lee Irwin III
2003-11-26 5:14 ` Martin J. Bligh [this message]
2003-11-26 9:51 ` William Lee Irwin III
2003-11-26 16:17 ` Martin J. Bligh
2003-11-26 7:25 ` Anton Blanchard
2003-11-26 5:53 Zhang, Yanmin
2003-11-29 10:39 Manfred Spraul
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='1590000.1069823671@[10.10.2.4]' \
--to=mbligh@aracnet.com \
--cc=akpm@osdl.org \
--cc=anton@samba.org \
--cc=jbarnes@sgi.com \
--cc=jes@trained-monkey.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.com \
--cc=steiner@sgi.com \
--cc=viro@math.psu.edu \
--cc=wli@holomorphy.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;
as well as URLs for NNTP newsgroup(s).