Annoyingly this seems to be intermittent, and I have not managed to get
a machine into this state again yet. Will keep trying.
-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
I have a couple of failed test runs against 2.6.23-rc6 where the
job timed out while running dbench over ext3. Both on powerpc,
though both significantly different hardware setups. A failed
run like this implies that the machine was still responsive to
other processes but the dbench was making
sting node with no memory we will not start one and we end up
with a node with memory and no kswapd. Bad.
As kswapd_run is a no-op when a kswapd already exists this seems a safe
way to fix that. Paul's ->zone conversion is obviously correct also.
Acked-by: Andy Whitcroft <[EMAIL PROTECTED]>
-ap
node with no memory we will not start one and we end up
with a node with memory and no kswapd. Bad.
As kswapd_run is a no-op when a kswapd already exists this seems a safe
way to fix that. Paul's -zone conversion is obviously correct also.
Acked-by: Andy Whitcroft [EMAIL PROTECTED]
-apw
I have a couple of failed test runs against 2.6.23-rc6 where the
job timed out while running dbench over ext3. Both on powerpc,
though both significantly different hardware setups. A failed
run like this implies that the machine was still responsive to
other processes but the dbench was making
Annoyingly this seems to be intermittent, and I have not managed to get
a machine into this state again yet. Will keep trying.
-apw
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
I have a couple of old NUMA-Q systems which are unable to read their
boot disks with 2.6.23-rc4-mm1. The disks appear to be recognised and
even the partition tables read correctly, and then they go pop:
qla1280: QLA1040 found on PCI bus 0, dev 10
Clocksource tsc unstable (delta = 99922590
Am seeing the following compile error on all of my powerpc platforms:
CC kernel/sched.o
kernel/sched.c: In function `cpu_to_phys_group':
kernel/sched.c:5937: error: `per_cpu__cpu_sibling_map' undeclared (first use
in this function)
kernel/sched.c:5937: error: (Each undeclared
Am seeing the following compile error on all of my powerpc platforms:
CC kernel/sched.o
kernel/sched.c: In function `cpu_to_phys_group':
kernel/sched.c:5937: error: `per_cpu__cpu_sibling_map' undeclared (first use
in this function)
kernel/sched.c:5937: error: (Each undeclared
I have a couple of old NUMA-Q systems which are unable to read their
boot disks with 2.6.23-rc4-mm1. The disks appear to be recognised and
even the partition tables read correctly, and then they go pop:
qla1280: QLA1040 found on PCI bus 0, dev 10
Clocksource tsc unstable (delta = 99922590
On Thu, Sep 06, 2007 at 10:07:12AM -0700, Shannon Nelson wrote:
> list_for_each_entry(iter, >async_tx.tx_list, node) {
> iter->hw->src_addr = addr;
> addr += ioat_chan->xfercap;
> +
> + if (--cnt == 0);
> + break;
> }
>
> }
On Thu, Sep 06, 2007 at 10:07:12AM -0700, Shannon Nelson wrote:
list_for_each_entry(iter, desc-async_tx.tx_list, node) {
iter-hw-src_addr = addr;
addr += ioat_chan-xfercap;
+
+ if (--cnt == 0);
+ break;
}
}
@@
Andi Kleen wrote:
> On Fri, Aug 24, 2007 at 06:44:38PM +0100, Mel Gorman wrote:
>> On (24/08/07 19:38), Andi Kleen didst pronounce:
Other than the fact that the memmap must be PMD aligned to use hugepage
entries for the memmap.
>>> Why is that so? mem_map should be just part of lowmem
Andi Kleen wrote:
On Fri, Aug 24, 2007 at 06:44:38PM +0100, Mel Gorman wrote:
On (24/08/07 19:38), Andi Kleen didst pronounce:
Other than the fact that the memmap must be PMD aligned to use hugepage
entries for the memmap.
Why is that so? mem_map should be just part of lowmem anyways.
Not
Andi Kleen wrote:
>> This reserved portion of the KVA must be PMD aligned.
>
> Why do they need to be PMD aligned?
That comes from the fact that the KVA in x86 has traditionally been
mapped with huge pages where at all possible, for performance reasons.
The purpose of the remap itself always
Mike Frysinger wrote:
> in some code that does like:
> #define foo { a, b, c, \
> d, e, f, g }
> ...
> int boo[] = foo;
> ...
>
> checkpatch.pl throws a fit:
> ERROR: Macros with complex values should be enclosed in parenthesis
> #10: FILE: ...
> +#define foo {a, b, c, d}
>
> perhaps the
Andrew Morton wrote:
>> +for_each_possible_cpu(cpu) {
>> +rbdp = per_cpu(rcu_boost_dat, cpu);
>> +for (i = 0; i < RCU_BOOST_ELEMENTS; i++) {
>> +rbdp[i].rbs_mutex = SPIN_LOCK_UNLOCKED;
>
> Doesn't this confound lockdep? We're supposed to use
Andrew Morton wrote:
+for_each_possible_cpu(cpu) {
+rbdp = per_cpu(rcu_boost_dat, cpu);
+for (i = 0; i RCU_BOOST_ELEMENTS; i++) {
+rbdp[i].rbs_mutex = SPIN_LOCK_UNLOCKED;
Doesn't this confound lockdep? We're supposed to use
Mike Frysinger wrote:
in some code that does like:
#define foo { a, b, c, \
d, e, f, g }
...
int boo[] = foo;
...
checkpatch.pl throws a fit:
ERROR: Macros with complex values should be enclosed in parenthesis
#10: FILE: ...
+#define foo {a, b, c, d}
perhaps the check should
Andi Kleen wrote:
This reserved portion of the KVA must be PMD aligned.
Why do they need to be PMD aligned?
That comes from the fact that the KVA in x86 has traditionally been
mapped with huge pages where at all possible, for performance reasons.
The purpose of the remap itself always has
Andrew Morton wrote:
> On Wed, 22 Aug 2007 14:15:16 -0500
> Dean Nelson <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Aug 22, 2007 at 11:04:22AM -0700, Andrew Morton wrote:
>>> On Wed, 22 Aug 2007 12:00:11 -0500
>>> Dean Nelson <[EMAIL PROTECTED]> wrote:
>>>
3) WARNING: declaring multiple
Andi Kleen wrote:
> On Thu, Aug 23, 2007 at 01:03:18PM +0100, Andy Whitcroft wrote:
>> It seems that this is a problem caused by the way we check for
>> compiler options in x86_64. Each compiler flag is checked for
>> individually and if available added to cflags-y, l
On Wed, Aug 22, 2007 at 11:10:29AM -0700, Andrew Morton wrote:
[...]
> > CC arch/x86_64/kernel/asm-offsets.s
> > arch/x86_64/kernel/asm-offsets.c:1: error: -mpreferred-stack-boundary=3
> > is not between 4 and 12
> > make[1]: *** [arch/x86_64/kernel/asm-offsets.s] Error 1
[...]
>
On Wed, Aug 22, 2007 at 11:10:29AM -0700, Andrew Morton wrote:
[...]
CC arch/x86_64/kernel/asm-offsets.s
arch/x86_64/kernel/asm-offsets.c:1: error: -mpreferred-stack-boundary=3
is not between 4 and 12
make[1]: *** [arch/x86_64/kernel/asm-offsets.s] Error 1
[...]
Andi Kleen wrote:
On Thu, Aug 23, 2007 at 01:03:18PM +0100, Andy Whitcroft wrote:
It seems that this is a problem caused by the way we check for
compiler options in x86_64. Each compiler flag is checked for
individually and if available added to cflags-y, later that is
added to CFLAGS
Andrew Morton wrote:
On Wed, 22 Aug 2007 14:15:16 -0500
Dean Nelson [EMAIL PROTECTED] wrote:
On Wed, Aug 22, 2007 at 11:04:22AM -0700, Andrew Morton wrote:
On Wed, 22 Aug 2007 12:00:11 -0500
Dean Nelson [EMAIL PROTECTED] wrote:
3) WARNING: declaring multiple variables together should be
Kok, Auke wrote:
> Joe Perches wrote:
>> On Wed, 2007-08-15 at 19:58 -0400, Dave Jones wrote:
>>> Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
>>>
>>> diff --git a/drivers/infiniband/hw/mlx4/mad.c
>>> b/drivers/infiniband/hw/mlx4/mad.c
>>> index 3330917..0ed02b7 100644
>>> ---
It seems a trailing ';' has slipped into mlx4_MAD_IFC() which causes
the response to be copied out unconditionally.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Cc: Roland Dreier <[EMAIL PROTECTED]>
Cc: Sean Hefty <[EMAIL PROTECTED]>
Cc: Hal Rosenstock <[EMAIL P
It seems an extraneous trailing ';' has slipped in to the error
handling for a name registration failure causing the error path to
trigger unconditionally.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Cc: Samuel Ortiz <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
---
net/irda
It seems an extraneous trailing ';' has slipped into the skb length
checks in u32_match_it() triggering an unconditional missmatch.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
---
net/netfilter/xt_u32.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-
Seems that a trailing ';' has slipped onto the end of the
get_slice_psize checks under CONFIG_PPC_MM_SLICES causing us to
return unconditionally and never preload.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
---
arc
It seems we have gained an extraneous trailing ';' on one of the
wait loops in scif_sercon_putc(). Although this is completely
benign as the apparent payload is also the empty statement, it
invites error in the future. Clean it up now.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Cc
Seems that a trailing ';' has slipped onto the end of the access_ok
check here, such that we will always return -EFAULT.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Cc: Ralf Baechle <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
---
arch/mips/kernel/irixsig.c |2 +-
1 file
A couple of people suggested adding checks to checkpatch for trailing
semicolons on conditionals, where the conditional block may not be
actually conditional:
if (err);
return err;
While regression testing the changes, I ran these checks across the
whole of 2.6.23-rc3 and
Eugene Teo wrote:
> Make checkpatch rant about trailing ; at the end of "if" expression.
>
> Thanks to Auke for the regexp.
>
> Signed-off by: Eugene Teo <[EMAIL PROTECTED]>
>
> --- checkpatch.pl-0.09.default2007-08-03 23:31:40.0 +0800
> +++ checkpatch.pl-0.092007-08-16
Eugene Teo wrote:
Make checkpatch rant about trailing ; at the end of if expression.
Thanks to Auke for the regexp.
Signed-off by: Eugene Teo [EMAIL PROTECTED]
--- checkpatch.pl-0.09.default2007-08-03 23:31:40.0 +0800
+++ checkpatch.pl-0.092007-08-16
A couple of people suggested adding checks to checkpatch for trailing
semicolons on conditionals, where the conditional block may not be
actually conditional:
if (err);
return err;
While regression testing the changes, I ran these checks across the
whole of 2.6.23-rc3 and
It seems an extraneous trailing ';' has slipped into the skb length
checks in u32_match_it() triggering an unconditional missmatch.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
---
net/netfilter/xt_u32.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
It seems we have gained an extraneous trailing ';' on one of the
wait loops in scif_sercon_putc(). Although this is completely
benign as the apparent payload is also the empty statement, it
invites error in the future. Clean it up now.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
Cc: Paul
Seems that a trailing ';' has slipped onto the end of the
get_slice_psize checks under CONFIG_PPC_MM_SLICES causing us to
return unconditionally and never preload.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
---
arch/powerpc/mm
Seems that a trailing ';' has slipped onto the end of the access_ok
check here, such that we will always return -EFAULT.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
Cc: Ralf Baechle [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
---
arch/mips/kernel/irixsig.c |2 +-
1 files changed, 1
It seems a trailing ';' has slipped into mlx4_MAD_IFC() which causes
the response to be copied out unconditionally.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
Cc: Roland Dreier [EMAIL PROTECTED]
Cc: Sean Hefty [EMAIL PROTECTED]
Cc: Hal Rosenstock [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED
It seems an extraneous trailing ';' has slipped in to the error
handling for a name registration failure causing the error path to
trigger unconditionally.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
Cc: Samuel Ortiz [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
---
net/irda/irnetlink.c |2
Kok, Auke wrote:
Joe Perches wrote:
On Wed, 2007-08-15 at 19:58 -0400, Dave Jones wrote:
Signed-off-by: Dave Jones [EMAIL PROTECTED]
diff --git a/drivers/infiniband/hw/mlx4/mad.c
b/drivers/infiniband/hw/mlx4/mad.c
index 3330917..0ed02b7 100644
--- a/drivers/infiniband/hw/mlx4/mad.c
+++
all others. It seems more correct to
follow this model when the SLIT information is missing or corrupt.
This patch updates the SLIT failure paths to fill in the NUMA node
distance table with this default.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
---
arch/ia64/kern
[EMAIL PROTECTED]
> P: Joel Schopp
> M: [EMAIL PROTECTED]
> S: Supported
> +F: scripts/checkpatch.pl
>
> COMMON INTERNET FILE SYSTEM (CIFS)
> P: Steve French
If this system goes in (and it seems sane enough) then this entry update
seems comprehensiv
: [EMAIL PROTECTED]
S: Supported
+F: scripts/checkpatch.pl
COMMON INTERNET FILE SYSTEM (CIFS)
P: Steve French
If this system goes in (and it seems sane enough) then this entry update
seems comprehensive.
Acked-by: Andy Whitcroft [EMAIL PROTECTED]
-apw
-
To unsubscribe from this list
. It seems more correct to
follow this model when the SLIT information is missing or corrupt.
This patch updates the SLIT failure paths to fill in the NUMA node
distance table with this default.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
---
arch/ia64/kernel/acpi.c | 62
jschopp wrote:
>> +# check for pointless casting of kmalloc return
>> +if ($rawline =~ /\*\)[ ]k[czm]alloc/) {
>
> It looks to me like this will catch
>
> foo = (char *) kmalloc(512);
>
> but not
>
> for = (char* )kmalloc(512);
>
> I haven't tried it but how about something like:
>
>
jschopp wrote:
+# check for pointless casting of kmalloc return
+if ($rawline =~ /\*\)[ ]k[czm]alloc/) {
It looks to me like this will catch
foo = (char *) kmalloc(512);
but not
for = (char* )kmalloc(512);
I haven't tried it but how about something like:
if($rawline
Krzysztof Helt wrote:
> On Thu, 9 Aug 2007 14:04:49 +0100
> Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
>> Seeing the following compile error on a G5 mac:
>>
>> drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
>> drivers/video/tdfxfb.c:1
On Fri, Aug 10, 2007 at 01:06:58PM +0530, Kamalesh Babulal wrote:
> Andrew Morton wrote:
> >On Fri, 10 Aug 2007 11:46:25 +0530 Kamalesh Babulal
> ><[EMAIL PROTECTED]> wrote:
> >
> >
> >>I get call trace, when the file system stress is run on the
> >>2.6.23-rc2-mm1 kernel on a Dual Core AMD
On Fri, Aug 10, 2007 at 01:06:58PM +0530, Kamalesh Babulal wrote:
Andrew Morton wrote:
On Fri, 10 Aug 2007 11:46:25 +0530 Kamalesh Babulal
[EMAIL PROTECTED] wrote:
I get call trace, when the file system stress is run on the
2.6.23-rc2-mm1 kernel on a Dual Core AMD Opteron
(processor
Krzysztof Helt wrote:
On Thu, 9 Aug 2007 14:04:49 +0100
Andy Whitcroft [EMAIL PROTECTED] wrote:
Seeing the following compile error on a G5 mac:
drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
drivers/video/tdfxfb.c:1341: error: 'opt' undeclared (first use
On Thu, Aug 09, 2007 at 04:20:06PM +0200, Krzysztof Helt wrote:
> On Thu, 9 Aug 2007 14:04:49 +0100
> Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
> > Seeing the following compile error on a G5 mac:
> >
> > drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
On Thu, Aug 09, 2007 at 01:53:06PM +0100, Andy Whitcroft wrote:
> Seeing spinlock bad magic BUG's from x86 and x86_64 test boxes,
> fsx-linux seems to be tickling it. Adding Peter as prop_norm_single
> seems to be his:
Talking to Peter on IRC he suggested I back out the patch below a
Seeing the following compile error on a G5 mac:
drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
drivers/video/tdfxfb.c:1341: error: 'opt' undeclared (first use in this
function)
drivers/video/tdfxfb.c:1341: error: (Each
Seeing spinlock bad magic BUG's from x86 and x86_64 test boxes,
fsx-linux seems to be tickling it. Adding Peter as prop_norm_single
seems to be his:
x86 (oai5-hs20):
BUG: spinlock bad magic on CPU#1, fsx-linux/25600
lock: c3c15a18, .magic: , .owner: /-1, .owner_cpu: 0
[]
Seeing spinlock bad magic BUG's from x86 and x86_64 test boxes,
fsx-linux seems to be tickling it. Adding Peter as prop_norm_single
seems to be his:
x86 (oai5-hs20):
BUG: spinlock bad magic on CPU#1, fsx-linux/25600
lock: c3c15a18, .magic: , .owner: none/-1, .owner_cpu: 0
[c01e28bc]
Seeing the following compile error on a G5 mac:
drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
drivers/video/tdfxfb.c:1341: error: 'opt' undeclared (first use in this
function)
drivers/video/tdfxfb.c:1341: error: (Each
On Thu, Aug 09, 2007 at 04:20:06PM +0200, Krzysztof Helt wrote:
On Thu, 9 Aug 2007 14:04:49 +0100
Andy Whitcroft [EMAIL PROTECTED] wrote:
Seeing the following compile error on a G5 mac:
drivers/video/tdfxfb.c: In function 'tdfxfb_setup':
drivers/video/tdfxfb.c:1341: error: 'opt
On Thu, Aug 09, 2007 at 01:53:06PM +0100, Andy Whitcroft wrote:
Seeing spinlock bad magic BUG's from x86 and x86_64 test boxes,
fsx-linux seems to be tickling it. Adding Peter as prop_norm_single
seems to be his:
Talking to Peter on IRC he suggested I back out the patch below and
retest
Improve code commentary on the initial writeback wait in synchronous
reclaim mode.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
---
mm/vmscan.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b1e9291..a6e65d0 100644
--
Andy Whitcroft wrote:
> Michal Piotrowski wrote:
>> Hi Andy,
>>
>> On 06/08/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>>> Between 2.6.23-rc1-git1 and 2.6.23-rc1-git2 we started getting the
>>> following fatal error during modpost on an x86_64
Andy Whitcroft wrote:
Michal Piotrowski wrote:
Hi Andy,
On 06/08/07, Andy Whitcroft [EMAIL PROTECTED] wrote:
Between 2.6.23-rc1-git1 and 2.6.23-rc1-git2 we started getting the
following fatal error during modpost on an x86_64 machine:
FATAL: drivers/acpi/video: sizeof(struct
Improve code commentary on the initial writeback wait in synchronous
reclaim mode.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
---
mm/vmscan.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index b1e9291..a6e65d0 100644
--- a/mm
Michal Piotrowski wrote:
> Hi Andy,
>
> On 06/08/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>> Between 2.6.23-rc1-git1 and 2.6.23-rc1-git2 we started getting the
>> following fatal error during modpost on an x86_64 machine:
>>
>> FATAL: drivers/acpi/
Between 2.6.23-rc1-git1 and 2.6.23-rc1-git2 we started getting the
following fatal error during modpost on an x86_64 machine:
FATAL: drivers/acpi/video: sizeof(struct acpi_device_id)=20 is not a
modulo of the size of section __mod_acpi_device_table=48.
Fix definition of struct
Between 2.6.23-rc1-git1 and 2.6.23-rc1-git2 we started getting the
following fatal error during modpost on an x86_64 machine:
FATAL: drivers/acpi/video: sizeof(struct acpi_device_id)=20 is not a
modulo of the size of section __mod_acpi_device_table=48.
Fix definition of struct
Michal Piotrowski wrote:
Hi Andy,
On 06/08/07, Andy Whitcroft [EMAIL PROTECTED] wrote:
Between 2.6.23-rc1-git1 and 2.6.23-rc1-git2 we started getting the
following fatal error during modpost on an x86_64 machine:
FATAL: drivers/acpi/video: sizeof(struct acpi_device_id)=20
them.
- parks the multple declaration support
- allows architecture defines in architecture specific headers
Andy Whitcroft (21):
Version: 0.09
loosen single statement brace checks
fix up multiple declaration to avoid function arguments
add some function space
Jan Engelhardt wrote:
> On Jul 23 2007 16:36, Kok, Auke wrote:
>> this somehow seems to match something completely non-related (a function
>> pointer declaration case):
>>
>> ERROR: no space between function name and open parenthesis '('
>> #7278: FILE: drivers/net/e1000e/hw.h:434:
>> + bool
Jan Engelhardt wrote:
On Jul 23 2007 16:36, Kok, Auke wrote:
this somehow seems to match something completely non-related (a function
pointer declaration case):
ERROR: no space between function name and open parenthesis '('
#7278: FILE: drivers/net/e1000e/hw.h:434:
+ bool
them.
- parks the multple declaration support
- allows architecture defines in architecture specific headers
Andy Whitcroft (21):
Version: 0.09
loosen single statement brace checks
fix up multiple declaration to avoid function arguments
add some function space
accounting (count deactivate events correctly)
- use our own sync/async flag type
[EMAIL PROTECTED]: update to version 2]
[EMAIL PROTECTED]: update to version 3]
Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
---
mm/vms
[This is a re-spin based on feedback from akpm.]
As pointed out by Mel when reclaim is applied at higher orders a
significant amount of IO may be started. As this takes finite time
to drain reclaim will consider more areas than ultimatly needed
to satisfy the request. This leads to more reclaim
We are transitioning pages from active to inactive in
clear_active_flags, those need counting as PGDEACTIVATE vm events.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Acked-by: Mel Gorman <[EMAIL PROTECTED]>
---
mm/vmscan.c |1 +
1 files changed, 1 insertions(+), 0 delet
ialisers, the x86_64 vmemmap
initialisation may incorrectly skip the last page of a section if
the section start is not aligned to the page.
Where we have a section spanning the end of a PMD we will check the
start of the section at A populating it. We will then move on 1
PMD page to C and find o
-by: Andy Whitcroft [EMAIL PROTECTED]
---
arch/x86_64/mm/init.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86_64/mm/init.c b/arch/x86_64/mm/init.c
index ac49df0..5d1ed03 100644
--- a/arch/x86_64/mm/init.c
+++ b/arch/x86_64/mm/init.c
@@ -792,9 +792,10 @@ int
[This is a re-spin based on feedback from akpm.]
As pointed out by Mel when reclaim is applied at higher orders a
significant amount of IO may be started. As this takes finite time
to drain reclaim will consider more areas than ultimatly needed
to satisfy the request. This leads to more reclaim
We are transitioning pages from active to inactive in
clear_active_flags, those need counting as PGDEACTIVATE vm events.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
Acked-by: Mel Gorman [EMAIL PROTECTED]
---
mm/vmscan.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
accounting (count deactivate events correctly)
- use our own sync/async flag type
[EMAIL PROTECTED]: update to version 2]
[EMAIL PROTECTED]: update to version 3]
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
---
mm/vmscan.c | 60
e node where it is known. Where it is not known defaulting
to -1 seems a better course, and would help us where node 0 is
short of memory.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
---
arch/i386/pci/common.c |2 ++
arch/i386/pci/fixup.c|8 +---
arch/i386/pci/numa.c
it is not known defaulting
to -1 seems a better course, and would help us where node 0 is
short of memory.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
---
arch/i386/pci/common.c |2 ++
arch/i386/pci/fixup.c|8 +---
arch/i386/pci/numa.c |8 +---
arch/i386/pci/visws.c
Jason Wessel wrote:
> Running checkpatch.pl products an warning when it should not. I believe
> it can be fixed by adding to the regular expression, but feel free to
> fix it another way as I may not know all the cases this is trying to catch.
Thanks for the patch. We had already caught this
Jason Wessel wrote:
Running checkpatch.pl products an warning when it should not. I believe
it can be fixed by adding to the regular expression, but feel free to
fix it another way as I may not know all the cases this is trying to catch.
Thanks for the patch. We had already caught this one
Andrew Morton wrote:
> On Sat, 28 Jul 2007 19:07:22 +0200 Gabriel C <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> next randconfig error (
>> http://194.231.229.228/MM/randconfig-auto-87.mm_sparse.error )
>>
>>
>> ...
>>
>> mm/sparse.c: In function 'sparse_init':
>> mm/sparse.c:482: error: implicit
Dan Williams wrote:
> WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
> #563: FILE: drivers/scsi/iioc34x/iioc34x_sas.c:58:
> +EXPORT_SYMBOL(iioc34x_transport_template);
>
> drivers/scsi/iioc34x/iioc34x_sas.c:57
> struct scsi_transport_template
Dan Williams wrote:
WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
#563: FILE: drivers/scsi/iioc34x/iioc34x_sas.c:58:
+EXPORT_SYMBOL(iioc34x_transport_template);
drivers/scsi/iioc34x/iioc34x_sas.c:57
struct scsi_transport_template *iioc34x_transport_template;
Andrew Morton wrote:
On Sat, 28 Jul 2007 19:07:22 +0200 Gabriel C [EMAIL PROTECTED] wrote:
Hi,
next randconfig error (
http://194.231.229.228/MM/randconfig-auto-87.mm_sparse.error )
...
mm/sparse.c: In function 'sparse_init':
mm/sparse.c:482: error: implicit declaration of function
memory but
that should be expected behaviour for high-order users. It is preferable
behaviour to potentially queueing unnecessary areas for IO. Note that kswapd
will not stall in this fashion.
[EMAIL PROTECTED]: update to version 2]
Signed-off-by: Mel Gorman <[EMAIL PROTECTED]>
Signed-off-by: An
We are transitioning pages from active to inactive in
clear_active_flags, those need counting as PGDEACTIVATE vm events.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Acked-by: Mel Gorman <[EMAIL PROTECTED]>
---
diff --git a/mm/vmscan.c b/mm/vmscan.c
index d419e10..99ec7fa 100
As pointed out by Mel when reclaim is applied at higher orders a
significant amount of IO may be started. As this takes finite time
to drain reclaim will consider more areas than ultimatly needed
to satisfy the request. This leads to more reclaim than strictly
required and reduced success rates.
As pointed out by Mel when reclaim is applied at higher orders a
significant amount of IO may be started. As this takes finite time
to drain reclaim will consider more areas than ultimatly needed
to satisfy the request. This leads to more reclaim than strictly
required and reduced success rates.
We are transitioning pages from active to inactive in
clear_active_flags, those need counting as PGDEACTIVATE vm events.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
Acked-by: Mel Gorman [EMAIL PROTECTED]
---
diff --git a/mm/vmscan.c b/mm/vmscan.c
index d419e10..99ec7fa 100644
--- a/mm
but
that should be expected behaviour for high-order users. It is preferable
behaviour to potentially queueing unnecessary areas for IO. Note that kswapd
will not stall in this fashion.
[EMAIL PROTECTED]: update to version 2]
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
Signed-off-by: Andy Whitcroft [EMAIL
Andy Whitcroft wrote:
> KAMEZAWA Hiroyuki wrote:
>> Fix sparsemem_vmemmap init. sorry if known bug.
>>
>> This patch fixes page table handling in sparsemem_vmammap.
>>
>> Without this, part of vmem_map is not mapped because each section's start
>> addr of
&
achy. This seems like a clean way to fix the bug.
Thanks for finding this.
Acked-by: Andy Whitcroft <[EMAIL PROTECTED]>
>
>
>
> ---
> mm/sparse.c | 24 +---
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> Index: devel-2.6.23-rc1-mm1/
table was introduced:
commit 89689ae7f95995723fbcd5c116c47933a3bb8b13
[PATCH] Get rid of zone_table[]
That conversion inadvertantly only initialised the node mapping in
SPARSEMEM_EXTREME. Ensure we initialise the node mapping in
SPARSEMEM_STATIC.
Signed-off-by: Andy Whitcroft <[EM
Andy Whitcroft wrote:
KAMEZAWA Hiroyuki wrote:
Fix sparsemem_vmemmap init. sorry if known bug.
This patch fixes page table handling in sparsemem_vmammap.
Without this, part of vmem_map is not mapped because each section's start
addr of
mem_map is not aligned to PGD/PMD/PUD.
(In ia64
501 - 600 of 940 matches
Mail list logo
