Pekka J Enberg wrote:
> [Andrew, I have been unable to find a NUMA-capable tester for this patch,
> so can we please put this in to -mm for some exposure?]
>
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> This patch cleans up __cache_alloc and __cache_alloc_node functions. We no
> longer need
Pekka J Enberg wrote:
[Andrew, I have been unable to find a NUMA-capable tester for this patch,
so can we please put this in to -mm for some exposure?]
From: Pekka Enberg [EMAIL PROTECTED]
This patch cleans up __cache_alloc and __cache_alloc_node functions. We no
longer need to do
Dave Hansen wrote:
I think the comments added say it pretty well, but I'll repeat it here.
This fix is pretty similar in concept to the one that Arnd posted
as a temporary workaround, but I've added a few comments explaining
what the actual assumptions are, and improved it a wee little bit.
Dave Hansen wrote:
I think the comments added say it pretty well, but I'll repeat it here.
This fix is pretty similar in concept to the one that Arnd posted
as a temporary workaround, but I've added a few comments explaining
what the actual assumptions are, and improved it a wee little bit.
Andrew Morton wrote:
On Wed, 6 Dec 2006 16:59:04 +
Andy Whitcroft <[EMAIL PROTECTED]> wrote:
This is a repost of the lumpy reclaim patch set.
more...
One concern is that when the code goes to reclaim a lump and fails, we end
up reclaiming a number of pages which we didn't reall
Andrew Morton wrote:
On Wed, 6 Dec 2006 16:59:04 +
Andy Whitcroft [EMAIL PROTECTED] wrote:
This is a repost of the lumpy reclaim patch set.
more...
One concern is that when the code goes to reclaim a lump and fails, we end
up reclaiming a number of pages which we didn't really want
Linus Torvalds wrote:
On Mon, 11 Dec 2006, Andy Whitcroft wrote:
I am afraid to report that this second version also fails for me, as you point
out CIFS can break us if defined.
Olaf, will you admit that the SLES9 code is crap now?
Andy, does just replacing the "__initdata" with &
Linus Torvalds wrote:
On Mon, 11 Dec 2006, Herbert Poetzl wrote:
cool!
should definitely work for all 'known' cases
No it doesn't.
Do a
git grep '".*Linux version .*"'
on the kernel, and see just how CRAP that "get_kernel_version" test is,
and has always been.
But let's hope
test.kernel.org testing seems to have shaken out a problem with the
kernel banner changing, introduced by this commit:
[PATCH] Fix linux banner utsname information
commit a2ee8649ba6d71416712e798276bf7c40b64e6e5
We first noticed it with 2.6.19-git13 as we use this version
test.kernel.org testing seems to have shaken out a problem with the
kernel banner changing, introduced by this commit:
[PATCH] Fix linux banner utsname information
commit a2ee8649ba6d71416712e798276bf7c40b64e6e5
We first noticed it with 2.6.19-git13 as we use this version
Linus Torvalds wrote:
On Mon, 11 Dec 2006, Herbert Poetzl wrote:
cool!
should definitely work for all 'known' cases
No it doesn't.
Do a
git grep '.*Linux version .*'
on the kernel, and see just how CRAP that get_kernel_version test is,
and has always been.
But let's hope that
Linus Torvalds wrote:
On Mon, 11 Dec 2006, Andy Whitcroft wrote:
I am afraid to report that this second version also fails for me, as you point
out CIFS can break us if defined.
Olaf, will you admit that the SLES9 code is crap now?
Andy, does just replacing the __initdata with const fix
and from the end of the inactive
list, increasing the chances of such areas coming free together.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Acked-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 85f626b..fc23d87 100644
--- a/mm/vmscan.c
+++ b
Zijlstra <[EMAIL PROTECTED]>
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
---
diff --git a/fs/buffer.c b/fs/buffer.c
index c953c15..2f8b073 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -374,7 +374,7 @@ static void free_more_memory(void)
for_each_online_pgdat(pgdat) {
This is a repost of the lumpy reclaim patch set. This is
basically unchanged from the last post, other than being rebased
to 2.6.19-rc2-mm2. This has passed basic stress testing on a range
of machines here.
[Sorry for the delay reposting, I had a test failure and needed
to confirm it was not
lumpy: ensure we respect zone boundaries
When scanning an aligned order N area ensure we only pull out pages
in the same zone as our tag page, else we will manipulate those
pages' LRU under the wrong zone lru_lock. Bad.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Acked-by: Peter Zi
the boundary pfn calculations.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
Acked-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 0f2d961..0effa3e 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -606,21 +606,14 @@ keep:
}
/*
- * zone->lru_
Peter Zijlstra wrote:
On Mon, 2006-12-04 at 11:30 -0800, Andrew Morton wrote:
I'd also like to pin down the situation with lumpy-reclaim versus
anti-fragmentation. No offence, but I would of course prefer to avoid
merging the anti-frag patches simply based on their stupendous size. It
seems
Peter Zijlstra wrote:
On Mon, 2006-12-04 at 11:30 -0800, Andrew Morton wrote:
I'd also like to pin down the situation with lumpy-reclaim versus
anti-fragmentation. No offence, but I would of course prefer to avoid
merging the anti-frag patches simply based on their stupendous size. It
seems
the boundary pfn calculations.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
Acked-by: Peter Zijlstra [EMAIL PROTECTED]
---
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 0f2d961..0effa3e 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -606,21 +606,14 @@ keep:
}
/*
- * zone-lru_lock is heavily contended
lumpy: ensure we respect zone boundaries
When scanning an aligned order N area ensure we only pull out pages
in the same zone as our tag page, else we will manipulate those
pages' LRU under the wrong zone lru_lock. Bad.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
Acked-by: Peter Zijlstra
This is a repost of the lumpy reclaim patch set. This is
basically unchanged from the last post, other than being rebased
to 2.6.19-rc2-mm2. This has passed basic stress testing on a range
of machines here.
[Sorry for the delay reposting, I had a test failure and needed
to confirm it was not
Zijlstra [EMAIL PROTECTED]
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
---
diff --git a/fs/buffer.c b/fs/buffer.c
index c953c15..2f8b073 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -374,7 +374,7 @@ static void free_more_memory(void)
for_each_online_pgdat(pgdat) {
zones
and from the end of the inactive
list, increasing the chances of such areas coming free together.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
Acked-by: Peter Zijlstra [EMAIL PROTECTED]
---
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 85f626b..fc23d87 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
Andrew Morton wrote:
On Mon, 4 Dec 2006 20:34:29 + (GMT)
Mel Gorman <[EMAIL PROTECTED]> wrote:
IOW: big-picture where-do-we-go-from-here stuff.
Start with lumpy reclaim,
I had lumpy-reclaim in my todo-queue but it seems to have gone away. I
think I need a lumpy-reclaim resend, please.
Mel Gorman wrote:
On Mon, 4 Dec 2006, Andrew Morton wrote:
, but I would of course prefer to avoid
merging the anti-frag patches simply based on their stupendous size.
It seems to me that lumpy-reclaim is suitable for the e1000 problem
, but perhaps not for the hugetlbpage problem.
I
Mel Gorman wrote:
On Mon, 4 Dec 2006, Andrew Morton wrote:
, but I would of course prefer to avoid
merging the anti-frag patches simply based on their stupendous size.
It seems to me that lumpy-reclaim is suitable for the e1000 problem
, but perhaps not for the hugetlbpage problem.
I
Andrew Morton wrote:
On Mon, 4 Dec 2006 20:34:29 + (GMT)
Mel Gorman [EMAIL PROTECTED] wrote:
IOW: big-picture where-do-we-go-from-here stuff.
Start with lumpy reclaim,
I had lumpy-reclaim in my todo-queue but it seems to have gone away. I
think I need a lumpy-reclaim resend, please.
this out as explicit
calls, also introduce a type for the callback function allowing them
to be type checked. For each callback we pre-declare the function,
causing a type error on definition rather than on use elsewhere.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
---
diff --git a/i
this out as explicit
calls, also introduce a type for the callback function allowing them
to be type checked. For each callback we pre-declare the function,
causing a type error on definition rather than on use elsewhere.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
---
diff --git a/include/linux
Kay Sievers wrote:
> On Tue, 2006-11-28 at 14:30 -0800, Greg KH wrote:
>> On Tue, Nov 28, 2006 at 12:35:43PM +0100, Mariusz Kozlowski wrote:
>>> Hello,
>>>
>>> When CONFIG_MODULE_UNLOAD is not set then this happens:
>>>
>>> CC kernel/module.o
>>> kernel/module.c:852: error: `initstate'
Kay Sievers wrote:
On Tue, 2006-11-28 at 14:30 -0800, Greg KH wrote:
On Tue, Nov 28, 2006 at 12:35:43PM +0100, Mariusz Kozlowski wrote:
Hello,
When CONFIG_MODULE_UNLOAD is not set then this happens:
CC kernel/module.o
kernel/module.c:852: error: `initstate' undeclared here (not
results in unspecified behavior
Move memory_setup() to avoid this.
Signed-off-by: Andy Whitcroft <[EMAIL PROTECTED]>
---
diff --git a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
index 8be04da..79df6e6 100644
--- a/arch/i386/kernel/setup.c
+++ b/arch/i386/kernel/setup.c
@@ -494,6 +
Andrew Morton wrote:
> On Sat, 25 Nov 2006 13:03:45 -0800
> "Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
>
>> On 2.6.18-rc7 and later during LTP:
>> http://test.kernel.org/abat/48393/debug/console.log
>
> The traces are a bit confusing, but I don't actually see anything wrong
> there. The
Andrew Morton wrote:
On Sat, 25 Nov 2006 13:03:45 -0800
Martin J. Bligh [EMAIL PROTECTED] wrote:
On 2.6.18-rc7 and later during LTP:
http://test.kernel.org/abat/48393/debug/console.log
The traces are a bit confusing, but I don't actually see anything wrong
there. The machine has used up
results in unspecified behavior
Move memory_setup() to avoid this.
Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
---
diff --git a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
index 8be04da..79df6e6 100644
--- a/arch/i386/kernel/setup.c
+++ b/arch/i386/kernel/setup.c
@@ -494,6 +494,12 @@ static
Andrew Morton wrote:
Dave Hansen <[EMAIL PROTECTED]> wrote:
The following four patches provide the last needed changes before the
introduction of sparsemem. For a more complete description of what this
will do, please see this patch:
Andrew Morton wrote:
Dave Hansen [EMAIL PROTECTED] wrote:
The following four patches provide the last needed changes before the
introduction of sparsemem. For a more complete description of what this
will do, please see this patch:
which is a patch against the 2.6.11.1 release. If consensus arrives
that this patch should be against the 2.6.11 tree, it will be done that
way in the future.
It seems to me that we have V (delta?) and VI (delta incremental) for
all the other kernel patch series. So perhaps we could have both,
which is a patch against the 2.6.11.1 release. If consensus arrives
that this patch should be against the 2.6.11 tree, it will be done that
way in the future.
It seems to me that we have V (delta?) and VI (delta incremental) for
all the other kernel patch series. So perhaps we could have both,
901 - 940 of 940 matches
Mail list logo
