* Re: 2.5.69-mm3
2003-05-08 8:39 2.5.69-mm3 Andrew Morton
@ 2003-05-09 14:10 ` Dipankar Sarma
2003-05-09 19:49 ` 2.5.69-mm3 Martin J. Bligh
` (2 more replies)
2003-05-09 14:53 ` 2.5.69-mm3 William Lee Irwin III
` (3 subsequent siblings)
4 siblings, 3 replies; 11+ messages in thread
From: Dipankar Sarma @ 2003-05-09 14:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Thu, May 08, 2003 at 08:41:12AM +0000, Andrew Morton wrote:
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.69-mm3.gz
>
> Will appear sometime at
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm3/
>
>
> Small things. Mainly a resync for various people...
>
> rcu-stats.patch
> RCU statistics reporting
I am wondering what we should do with this patch. The RCU stats display
the #s of RCU requests and actual updates on each CPU. On a normal system
they don't mean much to a sysadmin, so I am not sure if it is the right
thing to include this feature. OTOH, it is extremely useful to detect
potential memory leaks happening due to, say a CPU looping in
kernel (and RCU not happening consequently). Will a CONFIG_RCU_DEBUG
make it more palatable for mainline ?
Thanks
Dipankar
--
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:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: 2.5.69-mm3
2003-05-09 14:10 ` 2.5.69-mm3 Dipankar Sarma
@ 2003-05-09 19:49 ` Martin J. Bligh
2003-05-09 21:18 ` 2.5.69-mm3 Andrew Morton
2003-05-13 20:13 ` 2.5.69-mm3 Bill Davidsen
2 siblings, 0 replies; 11+ messages in thread
From: Martin J. Bligh @ 2003-05-09 19:49 UTC (permalink / raw)
To: dipankar, Andrew Morton; +Cc: linux-kernel, linux-mm
> I am wondering what we should do with this patch. The RCU stats display
> the #s of RCU requests and actual updates on each CPU. On a normal system
> they don't mean much to a sysadmin, so I am not sure if it is the right
> thing to include this feature. OTOH, it is extremely useful to detect
> potential memory leaks happening due to, say a CPU looping in
> kernel (and RCU not happening consequently). Will a CONFIG_RCU_DEBUG
> make it more palatable for mainline ?
I'd find that useful - if it has a measurable overhead. If not, just leave
it on all the time ;-)
M.
--
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:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.5.69-mm3
2003-05-09 14:10 ` 2.5.69-mm3 Dipankar Sarma
2003-05-09 19:49 ` 2.5.69-mm3 Martin J. Bligh
@ 2003-05-09 21:18 ` Andrew Morton
2003-05-13 20:13 ` 2.5.69-mm3 Bill Davidsen
2 siblings, 0 replies; 11+ messages in thread
From: Andrew Morton @ 2003-05-09 21:18 UTC (permalink / raw)
To: dipankar; +Cc: linux-kernel, linux-mm
Dipankar Sarma <dipankar@in.ibm.com> wrote:
>
> > rcu-stats.patch
> > RCU statistics reporting
>
> I am wondering what we should do with this patch.
How about we just keep it floating about in the experimental kernels?
Can't say that I use it for anything, really.
--
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:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.5.69-mm3
2003-05-09 14:10 ` 2.5.69-mm3 Dipankar Sarma
2003-05-09 19:49 ` 2.5.69-mm3 Martin J. Bligh
2003-05-09 21:18 ` 2.5.69-mm3 Andrew Morton
@ 2003-05-13 20:13 ` Bill Davidsen
2 siblings, 0 replies; 11+ messages in thread
From: Bill Davidsen @ 2003-05-13 20:13 UTC (permalink / raw)
To: Dipankar Sarma; +Cc: Andrew Morton, linux-kernel, linux-mm
On Fri, 9 May 2003, Dipankar Sarma wrote:
> I am wondering what we should do with this patch. The RCU stats display
> the #s of RCU requests and actual updates on each CPU. On a normal system
> they don't mean much to a sysadmin, so I am not sure if it is the right
> thing to include this feature. OTOH, it is extremely useful to detect
> potential memory leaks happening due to, say a CPU looping in
> kernel (and RCU not happening consequently). Will a CONFIG_RCU_DEBUG
> make it more palatable for mainline ?
Are there similar things, inplace or in patches? Perhaps a menu section
for kernel metrics and a nice little niche in /proc to display them?
Things like this are helpful when tuning a kernel, but perhaps not wanted
for the minimalist (like embedded) configs.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
--
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:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.5.69-mm3
2003-05-08 8:39 2.5.69-mm3 Andrew Morton
2003-05-09 14:10 ` 2.5.69-mm3 Dipankar Sarma
@ 2003-05-09 14:53 ` William Lee Irwin III
2003-05-09 15:37 ` 2.5.69-mm3 William Lee Irwin III
` (2 subsequent siblings)
4 siblings, 0 replies; 11+ messages in thread
From: William Lee Irwin III @ 2003-05-09 14:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Thu, May 08, 2003 at 01:39:58AM -0700, Andrew Morton wrote:
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.69-mm3.gz
> Will appear sometime at
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm3/
This comment looks stale; AIUI the behavior coded is what's desired.
This came up in a discussion with some implementors of a language
runtime about the cause of failures to open large files.
-- wli
diff -prauN linux-2.5.69-1/fs/open.c open-2.5.69-1/fs/open.c
--- linux-2.5.69-1/fs/open.c Wed Apr 9 06:42:36 2003
+++ open-2.5.69-1/fs/open.c Fri May 9 07:19:25 2003
@@ -902,7 +902,7 @@
/*
* Called when an inode is about to be open.
- * We use this to disallow opening RW large files on 32bit systems if
+ * We use this to disallow opening large files on 32bit systems if
* the caller didn't specify O_LARGEFILE. On 64bit systems we force
* on this flag in sys_open.
*/
--
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:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: 2.5.69-mm3
2003-05-08 8:39 2.5.69-mm3 Andrew Morton
2003-05-09 14:10 ` 2.5.69-mm3 Dipankar Sarma
2003-05-09 14:53 ` 2.5.69-mm3 William Lee Irwin III
@ 2003-05-09 15:37 ` William Lee Irwin III
2003-05-09 17:55 ` 2.5.69-mm3 William Lee Irwin III
2003-05-09 18:12 ` 2.5.69-mm3 William Lee Irwin III
4 siblings, 0 replies; 11+ messages in thread
From: William Lee Irwin III @ 2003-05-09 15:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Thu, May 08, 2003 at 01:39:58AM -0700, Andrew Morton wrote:
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.69-mm3.gz
> Will appear sometime at
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm3/
I was just looking over this and noticed 2.4.x makes u64 dma_addr_t
conditional on CONFIG_HIGHMEM64G where 2.5.x uses CONFIG_HIGHMEM. It's
clearly not necessary on CONFIG_HIGHMEM4G, hence this obvious (but
untested) patch:
-- wli
diff -prauN linux-2.5.69-1/include/asm-i386/types.h types-2.5.69-1/include/asm-i386/types.h
--- linux-2.5.69-1/include/asm-i386/types.h Mon Dec 30 20:14:21 2002
+++ types-2.5.69-1/include/asm-i386/types.h Fri May 9 08:29:57 2003
@@ -51,7 +51,7 @@
/* DMA addresses come in generic and 64-bit flavours. */
-#ifdef CONFIG_HIGHMEM
+#ifdef CONFIG_HIGHMEM64G
typedef u64 dma_addr_t;
#else
typedef u32 dma_addr_t;
--
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:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: 2.5.69-mm3
2003-05-08 8:39 2.5.69-mm3 Andrew Morton
` (2 preceding siblings ...)
2003-05-09 15:37 ` 2.5.69-mm3 William Lee Irwin III
@ 2003-05-09 17:55 ` William Lee Irwin III
2003-05-09 18:12 ` 2.5.69-mm3 William Lee Irwin III
4 siblings, 0 replies; 11+ messages in thread
From: William Lee Irwin III @ 2003-05-09 17:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Thu, May 08, 2003 at 01:39:58AM -0700, Andrew Morton wrote:
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.69-mm3.gz
> Will appear sometime at
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm3/
Microscopic hugetlb cleanup: some variables static to hugetlbpage.c are
later declared as extern within a function in the same file. This patch
removes their declaration.
-- wli
diff -urpN mm3-2.5.69-1/arch/i386/mm/hugetlbpage.c mm3-2.5.69-2/arch/i386/mm/hugetlbpage.c
--- mm3-2.5.69-1/arch/i386/mm/hugetlbpage.c 2003-05-04 16:53:41.000000000 -0700
+++ mm3-2.5.69-2/arch/i386/mm/hugetlbpage.c 2003-05-09 10:27:57.000000000 -0700
@@ -20,8 +20,6 @@
#include <asm/tlb.h>
#include <asm/tlbflush.h>
-#include <linux/sysctl.h>
-
static long htlbpagemem;
int htlbpage_max;
static long htlbzone_pages;
@@ -398,8 +396,6 @@ int set_hugetlb_mem_size(int count)
{
int lcount;
struct page *page;
- extern long htlbzone_pages;
- extern struct list_head htlbpage_freelist;
if (count < 0)
lcount = count;
--
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:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: 2.5.69-mm3
2003-05-08 8:39 2.5.69-mm3 Andrew Morton
` (3 preceding siblings ...)
2003-05-09 17:55 ` 2.5.69-mm3 William Lee Irwin III
@ 2003-05-09 18:12 ` William Lee Irwin III
2003-05-09 18:15 ` 2.5.69-mm3 William Lee Irwin III
4 siblings, 1 reply; 11+ messages in thread
From: William Lee Irwin III @ 2003-05-09 18:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linux-mm
On Thu, May 08, 2003 at 01:39:58AM -0700, Andrew Morton wrote:
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.69-mm3.gz
> Will appear sometime at
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.69/2.5.69-mm3/
topology.h has a syntactic hygiene issue where it has a for () loop with
an if () in the body defined as a macro:
#define foo(...) for (...) if (...)
This patch prepares some of the bitop definitions used for the loop
mechanics to be usable in headers where BITS_PER_LONG is not guaranteed
to be defined for some reason. It removes the #ifdef on BITS_PER_LONG
in favor of if (sizeof(...) == ...) tests so hweight_long() will be
defined even when BITS_PER_LONG is not. unsigned long is also used for
some variables and/or return types that changed size with BITS_PER_LONG.
The 32-bit generic_hweight64() also changed its argument from a pointer
to a u64, which actually makes for a consistent interface in both cases.
The follow-up will make use of this to clean up the hygiene issue above
and correct a compilation error in topology.h
-- wli
diff -urpN mm3-2.5.69-1/include/linux/bitops.h mm3-2.5.69-2/include/linux/bitops.h
--- mm3-2.5.69-1/include/linux/bitops.h 2003-05-09 09:22:16.000000000 -0700
+++ mm3-2.5.69-2/include/linux/bitops.h 2003-05-09 10:27:57.000000000 -0700
@@ -1,5 +1,6 @@
#ifndef _LINUX_BITOPS_H
#define _LINUX_BITOPS_H
+#include <asm/types.h>
#include <asm/bitops.h>
/*
@@ -107,11 +108,14 @@ static inline unsigned int generic_hweig
return (res & 0x0F) + ((res >> 4) & 0x0F);
}
-#if (BITS_PER_LONG == 64)
-
-static inline u64 generic_hweight64(u64 w)
+static inline unsigned long generic_hweight64(u64 w)
{
- u64 res = (w & 0x5555555555555555) + ((w >> 1) & 0x5555555555555555);
+ u64 res;
+ if (sizeof(unsigned long) == 4)
+ return generic_hweight32((unsigned long)(w >> 32)) +
+ generic_hweight32((unsigned long)w);
+
+ res = (w & 0x5555555555555555) + ((w >> 1) & 0x5555555555555555);
res = (res & 0x3333333333333333) + ((res >> 2) & 0x3333333333333333);
res = (res & 0x0F0F0F0F0F0F0F0F) + ((res >> 4) & 0x0F0F0F0F0F0F0F0F);
res = (res & 0x00FF00FF00FF00FF) + ((res >> 8) & 0x00FF00FF00FF00FF);
@@ -119,22 +123,9 @@ static inline u64 generic_hweight64(u64
return (res & 0x00000000FFFFFFFF) + ((res >> 32) & 0x00000000FFFFFFFF);
}
-#define hweight_long(w) generic_hweight64(w)
-
-#endif /* BITS_PER_LONG == 64 */
-
-#if (BITS_PER_LONG == 32)
-
-static inline unsigned int generic_hweight64(unsigned int *w)
+static inline unsigned long hweight_long(unsigned long x)
{
- return generic_hweight32(w[0]) + generic_hweight32(w[1]);
+ return sizeof(x) == 4 ? generic_hweight32(x) : generic_hweight64(x);
}
-#define hweight_long(w) generic_hweight32(w)
-
-#endif /* BITS_PER_LONG == 32 */
-
-#include <asm/bitops.h>
-
-
#endif
--
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:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: 2.5.69-mm3
2003-05-09 18:12 ` 2.5.69-mm3 William Lee Irwin III
@ 2003-05-09 18:15 ` William Lee Irwin III
2003-05-09 18:54 ` 2.5.69-mm3 William Lee Irwin III
0 siblings, 1 reply; 11+ messages in thread
From: William Lee Irwin III @ 2003-05-09 18:15 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux-mm
On Fri, May 09, 2003 at 11:12:57AM -0700, William Lee Irwin III wrote:
> topology.h has a syntactic hygiene issue where it has a for () loop with
> an if () in the body defined as a macro:
> #define foo(...) for (...) if (...)
> This patch prepares some of the bitop definitions used for the loop
> mechanics to be usable in headers where BITS_PER_LONG is not guaranteed
> to be defined for some reason. It removes the #ifdef on BITS_PER_LONG
> in favor of if (sizeof(...) == ...) tests so hweight_long() will be
> defined even when BITS_PER_LONG is not. unsigned long is also used for
> some variables and/or return types that changed size with BITS_PER_LONG.
> The 32-bit generic_hweight64() also changed its argument from a pointer
> to a u64, which actually makes for a consistent interface in both cases.
> The follow-up will make use of this to clean up the hygiene issue above
> and correct a compilation error in topology.h
diff -urpN mm3-2.5.69-1/include/linux/topology.h mm3-2.5.69-2/include/linux/topology.h
--- mm3-2.5.69-1/include/linux/topology.h 2003-05-09 09:22:16.000000000 -0700
+++ mm3-2.5.69-2/include/linux/topology.h 2003-05-09 10:29:08.000000000 -0700
@@ -32,8 +32,15 @@
#define nr_cpus_node(node) (hweight_long(node_to_cpumask(node)))
+static inline int __next_node_with_cpus(int node)
+{
+ do
+ ++node;
+ while (!nr_cpus_node(node) && node < numnodes);
+ return node;
+}
+
#define for_each_node_with_cpus(node) \
- for (node = 0; node < numnodes; node++) \
- if (nr_cpus_node(node)
+ for (node = 0; node < numnodes; node = __next_node_with_cpus(node))
#endif /* _LINUX_TOPOLOGY_H */
--
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:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: 2.5.69-mm3
2003-05-09 18:15 ` 2.5.69-mm3 William Lee Irwin III
@ 2003-05-09 18:54 ` William Lee Irwin III
0 siblings, 0 replies; 11+ messages in thread
From: William Lee Irwin III @ 2003-05-09 18:54 UTC (permalink / raw)
To: Andrew Morton, linux-kernel, linux-mm
On Fri, May 09, 2003 at 11:15:35AM -0700, William Lee Irwin III wrote:
+static inline int __next_node_with_cpus(int node)
+{
+ do
+ ++node;
+ while (!nr_cpus_node(node) && node < numnodes);
+ return node;
+}
GRRR, neither seems to hurt my booting it or cause warnings but there
are two mistakes:
(1) not checking node < numnodes before !nr_cpus_node()
(2) casting the arg of generic_hweight32() to unsigned long is wrong
Fixed patch(es) below.
-- wli
diff -urpN mm3-2.5.69-1/include/linux/bitops.h mm3-2.5.69-2/include/linux/bitops.h
--- mm3-2.5.69-1/include/linux/bitops.h 2003-05-09 09:22:16.000000000 -0700
+++ mm3-2.5.69-2/include/linux/bitops.h 2003-05-09 11:30:09.000000000 -0700
@@ -1,5 +1,6 @@
#ifndef _LINUX_BITOPS_H
#define _LINUX_BITOPS_H
+#include <asm/types.h>
#include <asm/bitops.h>
/*
@@ -107,11 +108,14 @@ static inline unsigned int generic_hweig
return (res & 0x0F) + ((res >> 4) & 0x0F);
}
-#if (BITS_PER_LONG == 64)
-
-static inline u64 generic_hweight64(u64 w)
+static inline unsigned long generic_hweight64(u64 w)
{
- u64 res = (w & 0x5555555555555555) + ((w >> 1) & 0x5555555555555555);
+ u64 res;
+ if (sizeof(unsigned long) == 4)
+ return generic_hweight32((unsigned int)(w >> 32)) +
+ generic_hweight32((unsigned int)w);
+
+ res = (w & 0x5555555555555555) + ((w >> 1) & 0x5555555555555555);
res = (res & 0x3333333333333333) + ((res >> 2) & 0x3333333333333333);
res = (res & 0x0F0F0F0F0F0F0F0F) + ((res >> 4) & 0x0F0F0F0F0F0F0F0F);
res = (res & 0x00FF00FF00FF00FF) + ((res >> 8) & 0x00FF00FF00FF00FF);
@@ -119,22 +123,9 @@ static inline u64 generic_hweight64(u64
return (res & 0x00000000FFFFFFFF) + ((res >> 32) & 0x00000000FFFFFFFF);
}
-#define hweight_long(w) generic_hweight64(w)
-
-#endif /* BITS_PER_LONG == 64 */
-
-#if (BITS_PER_LONG == 32)
-
-static inline unsigned int generic_hweight64(unsigned int *w)
+static inline unsigned long hweight_long(unsigned long x)
{
- return generic_hweight32(w[0]) + generic_hweight32(w[1]);
+ return sizeof(x) == 4 ? generic_hweight32(x) : generic_hweight64(x);
}
-#define hweight_long(w) generic_hweight32(w)
-
-#endif /* BITS_PER_LONG == 32 */
-
-#include <asm/bitops.h>
-
-
#endif
diff -urpN mm3-2.5.69-1/include/linux/topology.h mm3-2.5.69-2/include/linux/topology.h
--- mm3-2.5.69-1/include/linux/topology.h 2003-05-09 09:22:16.000000000 -0700
+++ mm3-2.5.69-2/include/linux/topology.h 2003-05-09 11:29:52.000000000 -0700
@@ -32,8 +32,15 @@
#define nr_cpus_node(node) (hweight_long(node_to_cpumask(node)))
+static inline int __next_node_with_cpus(int node)
+{
+ do
+ ++node;
+ while (node < numnodes && !nr_cpus_node(node));
+ return node;
+}
+
#define for_each_node_with_cpus(node) \
- for (node = 0; node < numnodes; node++) \
- if (nr_cpus_node(node)
+ for (node = 0; node < numnodes; node = __next_node_with_cpus(node))
#endif /* _LINUX_TOPOLOGY_H */
--
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:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply [flat|nested] 11+ messages in thread