linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] use NODES_SHIFT to calculate ZONE_SHIFT
@ 2003-11-05 21:16 Jesse Barnes
  2003-11-07 21:58 ` Andrew Morton
  0 siblings, 1 reply; 3+ messages in thread
From: Jesse Barnes @ 2003-11-05 21:16 UTC (permalink / raw)
  To: akpm, linux-kernel

Now that we have a proper NODES_SHIFT value, we need to use it to define
ZONE_SHIFT otherwise we'll spill over 8 bits if we have more than 85
nodes.  How does this look?  The '+2' should really be
log2(MAX_NR_NODES), but I think this is an improvement over what was
there.

Thanks,
Jesse

===== include/linux/mm.h 1.133 vs edited =====
--- 1.133/include/linux/mm.h	Sun Oct  5 01:07:49 2003
+++ edited/include/linux/mm.h	Tue Nov  4 16:45:33 2003
@@ -322,8 +322,10 @@
 /*
  * The zone field is never updated after free_area_init_core()
  * sets it, so none of the operations on it need to be atomic.
+ * We'll have up to log2(MAX_NUMNODES * MAX_NR_ZONES) zones
+ * total, so we use NODES_SHIFT here to get enough bits.
  */
-#define ZONE_SHIFT (BITS_PER_LONG - 8)
+#define ZONE_SHIFT (BITS_PER_LONG - (NODES_SHIFT + 2))
 
 struct zone;
 extern struct zone *zone_table[];

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] use NODES_SHIFT to calculate ZONE_SHIFT
  2003-11-05 21:16 [PATCH] use NODES_SHIFT to calculate ZONE_SHIFT Jesse Barnes
@ 2003-11-07 21:58 ` Andrew Morton
  2003-11-07 22:01   ` Jesse Barnes
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2003-11-07 21:58 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: linux-kernel

jbarnes@sgi.com (Jesse Barnes) wrote:
>
> Now that we have a proper NODES_SHIFT value, we need to use it to define
> ZONE_SHIFT otherwise we'll spill over 8 bits if we have more than 85
> nodes.  How does this look?  The '+2' should really be
> log2(MAX_NR_NODES), but I think this is an improvement over what was
> there.

You mean log2(MAX_NR_ZONES).

How about we do it this way, so at least the duplicated information is on
adjacent lines, and they are unlikely to get out of sync?


 
diff -puN include/linux/mm.h~ZONE_SHIFT-from-NODES_SHIFT include/linux/mm.h
--- 25/include/linux/mm.h~ZONE_SHIFT-from-NODES_SHIFT	Fri Nov  7 13:51:22 2003
+++ 25-akpm/include/linux/mm.h	Fri Nov  7 13:55:11 2003
@@ -322,8 +322,10 @@ static inline void put_page(struct page 
 /*
  * The zone field is never updated after free_area_init_core()
  * sets it, so none of the operations on it need to be atomic.
+ * We'll have up to log2(MAX_NUMNODES * MAX_NR_ZONES) zones
+ * total, so we use NODES_SHIFT here to get enough bits.
  */
-#define ZONE_SHIFT (BITS_PER_LONG - 8)
+#define ZONE_SHIFT (BITS_PER_LONG - NODES_SHIFT - MAX_NR_ZONES_SHIFT)
 
 struct zone;
 extern struct zone *zone_table[];
diff -puN include/linux/mmzone.h~ZONE_SHIFT-from-NODES_SHIFT include/linux/mmzone.h
--- 25/include/linux/mmzone.h~ZONE_SHIFT-from-NODES_SHIFT	Fri Nov  7 13:51:49 2003
+++ 25-akpm/include/linux/mmzone.h	Fri Nov  7 13:57:19 2003
@@ -159,7 +159,10 @@ struct zone {
 #define ZONE_DMA		0
 #define ZONE_NORMAL		1
 #define ZONE_HIGHMEM		2
-#define MAX_NR_ZONES		3
+
+#define MAX_NR_ZONES		3	/* Sync this with MAX_NR_ZONES_SHIFT */
+#define MAX_NR_ZONES_SHIFT	2	/* ceil(log2(MAX_NR_ZONES)) */
+
 #define GFP_ZONEMASK	0x03
 
 /*

_


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] use NODES_SHIFT to calculate ZONE_SHIFT
  2003-11-07 21:58 ` Andrew Morton
@ 2003-11-07 22:01   ` Jesse Barnes
  0 siblings, 0 replies; 3+ messages in thread
From: Jesse Barnes @ 2003-11-07 22:01 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Fri, Nov 07, 2003 at 01:58:06PM -0800, Andrew Morton wrote:
> jbarnes@sgi.com (Jesse Barnes) wrote:
> >
> > Now that we have a proper NODES_SHIFT value, we need to use it to define
> > ZONE_SHIFT otherwise we'll spill over 8 bits if we have more than 85
> > nodes.  How does this look?  The '+2' should really be
> > log2(MAX_NR_NODES), but I think this is an improvement over what was
> > there.
> 
> You mean log2(MAX_NR_ZONES).

Yep, sorry.

> How about we do it this way, so at least the duplicated information is on
> adjacent lines, and they are unlikely to get out of sync?

Yeah, this looks great.

Thanks,
Jesse

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-11-07 22:33 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-05 21:16 [PATCH] use NODES_SHIFT to calculate ZONE_SHIFT Jesse Barnes
2003-11-07 21:58 ` Andrew Morton
2003-11-07 22:01   ` Jesse Barnes

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).