Natalie Protasevich wrote:
On 9/23/07, David Woodhouse <[EMAIL PROTECTED]> wrote:
On Sun, 2007-09-23 at 11:08 -0700, Natalie Protasevich wrote:
On 9/23/07, Diego Calleja <[EMAIL PROTECTED]> wrote:
Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710
bugzilla tries to send a mail to
Natalie Protasevich wrote:
On 9/23/07, David Woodhouse [EMAIL PROTECTED] wrote:
On Sun, 2007-09-23 at 11:08 -0700, Natalie Protasevich wrote:
On 9/23/07, Diego Calleja [EMAIL PROTECTED] wrote:
Take a look at http://bugzilla.kernel.org/show_bug.cgi?id=3710
bugzilla tries to send a mail to the
Christoph Lameter wrote:
On Tue, 11 Sep 2007, Nick Piggin wrote:
But that's not my place to say, and I'm actually not arguing that high
order pagecache does not have uses (especially as a practical,
shorter-term solution which is unintrusive to filesystems).
So no, I don't think I'm really
Christoph Lameter wrote:
On Tue, 11 Sep 2007, Nick Piggin wrote:
But that's not my place to say, and I'm actually not arguing that high
order pagecache does not have uses (especially as a practical,
shorter-term solution which is unintrusive to filesystems).
So no, I don't think I'm really
Christoph Hellwig wrote:
On Sat, Aug 04, 2007 at 09:42:59PM +0200, J??rn Engel wrote:
On Sat, 4 August 2007 21:26:15 +0200, J??rn Engel wrote:
Given the choice between only "atime" and "noatime" I'd agree with you.
Heck, I use it myself. But "relatime" seems to combine the best of
Christoph Hellwig wrote:
On Sat, Aug 04, 2007 at 09:42:59PM +0200, J??rn Engel wrote:
On Sat, 4 August 2007 21:26:15 +0200, J??rn Engel wrote:
Given the choice between only atime and noatime I'd agree with you.
Heck, I use it myself. But relatime seems to combine the best of both
Christoph Hellwig wrote:
On Tue, Jun 26, 2007 at 12:35:09PM +1000, Nick Piggin wrote:
I'd like to see you there, so I hope we can find a date that most
people are happy with. I'll try to start working that out after we
have a rough idea of who's interested.
Do we have any data
Christoph Hellwig wrote:
On Tue, Jun 26, 2007 at 12:35:09PM +1000, Nick Piggin wrote:
I'd like to see you there, so I hope we can find a date that most
people are happy with. I'll try to start working that out after we
have a rough idea of who's interested.
Do we have any data
Yes, good work, thanks a lot for it! The new interface is much better and more
useful.
Greetings,
Rafael
PS
BTW, would that be possible to create the "Hibernation/Suspend" subcategory
of "Power Management" that I asked for some time ago, please? :-)
Oops. Sorry. Done.
M.
-
To
Yes, good work, thanks a lot for it! The new interface is much better and more
useful.
Greetings,
Rafael
PS
BTW, would that be possible to create the Hibernation/Suspend subcategory
of Power Management that I asked for some time ago, please? :-)
Oops. Sorry. Done.
M.
-
To unsubscribe
Adrian Bunk wrote:
On Sat, Jun 02, 2007 at 01:42:06AM +0200, Rafael J. Wysocki wrote:
Hi,
Can anyone please tell me who's administering the kernel bugzilla now?
I've tried to write to [EMAIL PROTECTED] , but this address seems
to point to nowhere.
...
Martin Bligh (explicitely Cc'ed) should
Adrian Bunk wrote:
On Sat, Jun 02, 2007 at 01:42:06AM +0200, Rafael J. Wysocki wrote:
Hi,
Can anyone please tell me who's administering the kernel bugzilla now?
I've tried to write to [EMAIL PROTECTED] , but this address seems
to point to nowhere.
...
Martin Bligh (explicitely Cc'ed) should
Bas Westerbaan wrote:
Hello,
Quite a lot of userspace applications cache. Firefox caches pages;
mySQL caches queries; libc' free (like practically all other
userspace allocators) won't directly return the first byte of memory
freed, etc.
These applications are unaware of memory pressure.
Bas Westerbaan wrote:
Hello,
Quite a lot of userspace applications cache. Firefox caches pages;
mySQL caches queries; libc' free (like practically all other
userspace allocators) won't directly return the first byte of memory
freed, etc.
These applications are unaware of memory pressure.
Sorry, have been out sick, and someone removed me from the cc list,
which didn't help. In response to various bits:
Firstly a general comment - we're about to upgrade versions, which
will ease a few of these issues. I should really finish the creation
of virtual category owners for *all*
Sorry, have been out sick, and someone removed me from the cc list,
which didn't help. In response to various bits:
Firstly a general comment - we're about to upgrade versions, which
will ease a few of these issues. I should really finish the creation
of virtual category owners for *all*
The thing is, these reports MUST NOT go to "everybody". If they do, that
is actually *worse* than nothing, because people will just ignore them
entirely, since they aren't "directed".
The emails need to be directed to the appropriate parties, not go to
everybody. There is nobody who is
The thing is, these reports MUST NOT go to everybody. If they do, that
is actually *worse* than nothing, because people will just ignore them
entirely, since they aren't directed.
The emails need to be directed to the appropriate parties, not go to
everybody. There is nobody who is interested
cc: apw ... seeing as he wrote sparsemem in the first place, please copy
him on this stuff ?
Andi Kleen wrote:
On Monday 02 April 2007 17:37, Christoph Lameter wrote:
On Sun, 1 Apr 2007, Andi Kleen wrote:
Hmm, this means there is at least 2MB worth of struct page on every node?
Or do you
cc: apw ... seeing as he wrote sparsemem in the first place, please copy
him on this stuff ?
Andi Kleen wrote:
On Monday 02 April 2007 17:37, Christoph Lameter wrote:
On Sun, 1 Apr 2007, Andi Kleen wrote:
Hmm, this means there is at least 2MB worth of struct page on every node?
Or do you
Christoph Lameter wrote:
On Fri, 2 Mar 2007, William Lee Irwin III wrote:
On Fri, Mar 02, 2007 at 02:22:56PM -0800, Andrew Morton wrote:
Opterons seem to be particularly prone to lock starvation where a cacheline
gets captured in a single package for ever.
AIUI that phenomenon is universal
Christoph Lameter wrote:
On Fri, 2 Mar 2007, William Lee Irwin III wrote:
On Fri, Mar 02, 2007 at 02:22:56PM -0800, Andrew Morton wrote:
Opterons seem to be particularly prone to lock starvation where a cacheline
gets captured in a single package for ever.
AIUI that phenomenon is universal
.. and think about a realistic future.
EVERYBODY will do on-die memory controllers. Yes, Intel doesn't do it
today, but in the one- to two-year timeframe even Intel will.
What does that mean? It means that in bigger systems, you will no longer
even *have* 8 or 16 banks where turning off a
32GB is pretty much the minimum size to reproduce some of these
problems. Some workloads may need larger systems to easily trigger
them.
We can find a 32GB system here pretty easily to test things on if
need be. Setting up large commercial databases is much harder.
That's my problem, too.
32GB is pretty much the minimum size to reproduce some of these
problems. Some workloads may need larger systems to easily trigger
them.
We can find a 32GB system here pretty easily to test things on if
need be. Setting up large commercial databases is much harder.
That's my problem, too.
.. and think about a realistic future.
EVERYBODY will do on-die memory controllers. Yes, Intel doesn't do it
today, but in the one- to two-year timeframe even Intel will.
What does that mean? It means that in bigger systems, you will no longer
even *have* 8 or 16 banks where turning off a
Andi Kleen wrote:
I wasn't suggesting having NULL pointers for pgdats, if that's what you
mean.
That is what started the original thread at least. Can happen on some
ia64 platforms.
OK, that does seem kind of ugly.
Just nodes with no memory in them, the pgdat would still be there.
pgdat =
Christoph Lameter wrote:
On Tue, 13 Feb 2007, Andi Kleen wrote:
Adding NULL tests all over mm for this would seem like a clear case
of this to me.
Maybe there is an alternative. We are free to number the nodes right?
How about requiring the low node number to have memory and the high ones
Andi Kleen wrote:
Your description of the node is correct, it's an arbitrary container of
one or more resources. Not only is this definition flexible, it's also
very useful, for memory hotplug, odd types of NUMA boxes, etc.
I must disagree here. Special cases are always dangerous especially
if
KAMEZAWA Hiroyuki wrote:
In my last posintg, mempolicy-fix-for-memory-less-node patch, there was a
discussion 'what do you consider definition of "node" as...?
I found there is no consensus. But I want to go ahead.
Before posing patch again, I'd like to discuss more.
-Kame
In my
KAMEZAWA Hiroyuki wrote:
In my last posintg, mempolicy-fix-for-memory-less-node patch, there was a
discussion 'what do you consider definition of node as...?
I found there is no consensus. But I want to go ahead.
Before posing patch again, I'd like to discuss more.
-Kame
In my understanding,
Andi Kleen wrote:
Your description of the node is correct, it's an arbitrary container of
one or more resources. Not only is this definition flexible, it's also
very useful, for memory hotplug, odd types of NUMA boxes, etc.
I must disagree here. Special cases are always dangerous especially
if
Christoph Lameter wrote:
On Tue, 13 Feb 2007, Andi Kleen wrote:
Adding NULL tests all over mm for this would seem like a clear case
of this to me.
Maybe there is an alternative. We are free to number the nodes right?
How about requiring the low node number to have memory and the high ones
Andi Kleen wrote:
I wasn't suggesting having NULL pointers for pgdats, if that's what you
mean.
That is what started the original thread at least. Can happen on some
ia64 platforms.
OK, that does seem kind of ugly.
Just nodes with no memory in them, the pgdat would still be there.
pgdat =
Christoph Hellwig wrote:
On Fri, Feb 02, 2007 at 10:20:12PM -0800, Christoph Lameter wrote:
This is a new variation on the earlier RFC for tracking mlocked pages.
We now mark a mlocked page with a bit in the page flags and remove
them from the LRU. Pages get moved back when no vma that
Christoph Hellwig wrote:
On Fri, Feb 02, 2007 at 10:20:12PM -0800, Christoph Lameter wrote:
This is a new variation on the earlier RFC for tracking mlocked pages.
We now mark a mlocked page with a bit in the page flags and remove
them from the LRU. Pages get moved back when no vma that
Jeff Garzik wrote:
Robert Hancock wrote:
Jeff Garzik wrote:
* Include the patch inline rather than as an attachment. Even a
text/plain attachment is very difficult to review and quote in
popular email programs.
Jeff
I'd love to, but unfortunately nobody seems to have come up with a
Jeff Garzik wrote:
Robert Hancock wrote:
Jeff Garzik wrote:
* Include the patch inline rather than as an attachment. Even a
text/plain attachment is very difficult to review and quote in
popular email programs.
Jeff
I'd love to, but unfortunately nobody seems to have come up with a
I finally re-ran memtest86 on the machine since it began to have too
many different kind of errors (GPF, invalid instruction...). It turned
out that one of the memory modules was bad. I guess my brand new
list_debug race condition debugger will be useful in the future, but not
now. :)
I'll
Andrew Morton wrote:
On Mon, 29 Jan 2007 17:31:20 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic(). Par
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic(). Partly because kmap() is deadlockable in situations where a
large number of threads are trying to take two kmaps at the same
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic(). Partly because kmap() is deadlockable in situations where a
large number of threads are trying to take two kmaps at the same
Andrew Morton wrote:
On Mon, 29 Jan 2007 17:31:20 -0800
Martin J. Bligh [EMAIL PROTECTED] wrote:
Peter Zijlstra wrote:
On Sun, 2007-01-28 at 14:29 -0800, Andrew Morton wrote:
As Christoph says, it's very much preferred that code be migrated over to
kmap_atomic(). Partly because kmap
I finally re-ran memtest86 on the machine since it began to have too
many different kind of errors (GPF, invalid instruction...). It turned
out that one of the memory modules was bad. I guess my brand new
list_debug race condition debugger will be useful in the future, but not
now. :)
I'll
Arjan van de Ven wrote:
On Sun, 2007-01-28 at 17:04 +, Christoph Hellwig wrote:
On Sun, Jan 28, 2007 at 08:52:25AM -0800, Martin J. Bligh wrote:
Mmm. not wholly convinced that's true. Whilst i don't have lockmeter
stats to hand, the heavy time in __d_lookup seems to indicate we may
still
Andrew Morton wrote:
On Sun, 28 Jan 2007 08:56:08 -0800
"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
- It seems that people have been busy creating the need for this. I had to
apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation
errors. And a n
Mathieu Desnoyers wrote:
Hi,
Trying to build cross-compilers (or kernels) on a 2-way x86_64 (amd64) with
make -j3 triggers the following OOPS after about 30 minutes on
2.6.19.2. Due to the amount of time and the heavy load it takes before it
happens, I suspect a race condition. Memtest86 tests
Christoph Hellwig wrote:
On Sun, Jan 28, 2007 at 08:52:25AM -0800, Martin J. Bligh wrote:
Mmm. not wholly convinced that's true. Whilst i don't have lockmeter
stats to hand, the heavy time in __d_lookup seems to indicate we may
still have a problem to me. I guess we could move the spinlocks out
- It seems that people have been busy creating the need for this. I had to
apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation
errors. And a number of patches were dropped due to no-compile or to
runtime errors. Heaven knows how many runtime bugs were added.
- It seems that people have been busy creating the need for this. I had to
apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation
errors. And a number of patches were dropped due to no-compile or to
runtime errors. Heaven knows how many runtime bugs were added.
- It seems that people have been busy creating the need for this. I had to
apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation
errors. And a number of patches were dropped due to no-compile or to
runtime errors. Heaven knows how many runtime bugs were added.
Ingo Molnar wrote:
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
On Sun, Jan 28, 2007 at 12:51:18PM +0100, Peter Zijlstra wrote:
This patch-set breaks up the global file_list_lock which was found
to be a severe contention point under basically any filesystem
intensive workload.
Benchmarks,
Ingo Molnar wrote:
* Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sun, Jan 28, 2007 at 12:51:18PM +0100, Peter Zijlstra wrote:
This patch-set breaks up the global file_list_lock which was found
to be a severe contention point under basically any filesystem
intensive workload.
Benchmarks,
- It seems that people have been busy creating the need for this. I had to
apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation
errors. And a number of patches were dropped due to no-compile or to
runtime errors. Heaven knows how many runtime bugs were added.
- It seems that people have been busy creating the need for this. I had to
apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation
errors. And a number of patches were dropped due to no-compile or to
runtime errors. Heaven knows how many runtime bugs were added.
- It seems that people have been busy creating the need for this. I had to
apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation
errors. And a number of patches were dropped due to no-compile or to
runtime errors. Heaven knows how many runtime bugs were added.
Christoph Hellwig wrote:
On Sun, Jan 28, 2007 at 08:52:25AM -0800, Martin J. Bligh wrote:
Mmm. not wholly convinced that's true. Whilst i don't have lockmeter
stats to hand, the heavy time in __d_lookup seems to indicate we may
still have a problem to me. I guess we could move the spinlocks out
Mathieu Desnoyers wrote:
Hi,
Trying to build cross-compilers (or kernels) on a 2-way x86_64 (amd64) with
make -j3 triggers the following OOPS after about 30 minutes on
2.6.19.2. Due to the amount of time and the heavy load it takes before it
happens, I suspect a race condition. Memtest86 tests
Andrew Morton wrote:
On Sun, 28 Jan 2007 08:56:08 -0800
Martin J. Bligh [EMAIL PROTECTED] wrote:
- It seems that people have been busy creating the need for this. I had to
apply over sixty patches to this tree to fix post-2.6.20-rc4-mm1 compilation
errors. And a number of patches were
Arjan van de Ven wrote:
On Sun, 2007-01-28 at 17:04 +, Christoph Hellwig wrote:
On Sun, Jan 28, 2007 at 08:52:25AM -0800, Martin J. Bligh wrote:
Mmm. not wholly convinced that's true. Whilst i don't have lockmeter
stats to hand, the heavy time in __d_lookup seems to indicate we may
still
Andrew Morton wrote:
On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Tue, 9 Jan 2007, Andrew Morton wrote:
This new behavior of the kernel build system is likely to
make developers angry pretty quickly.
That might motivate them to fix it ;)
Actually,
Andrew Morton wrote:
On Tue, 9 Jan 2007 15:21:51 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Tue, 9 Jan 2007, Andrew Morton wrote:
This new behavior of the kernel build system is likely to
make developers angry pretty quickly.
That might motivate them to fix it ;)
Actually, how
Jeff V. Merkey wrote:
Again, I agree with EVERY statement Linus made here. We operate exactly
as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of
affected kernel code
(albiet the code resembles what Linus describes as a "skeleton driver")
and our
Dave Jones wrote:
On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
> The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
> going. If we don't stand up at some point, and ban binary drivers, we
> will, I fear, end up with an unsustainable
Dave Jones wrote:
On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote:
The Ubuntu feisty fawn mess was a dangerous warning bell of where we're
going. If we don't stand up at some point, and ban binary drivers, we
will, I fear, end up with an unsustainable ecosystem for Linux
Jeff V. Merkey wrote:
Again, I agree with EVERY statement Linus made here. We operate exactly
as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of
affected kernel code
(albiet the code resembles what Linus describes as a skeleton driver)
and our
Linus Torvalds wrote:
On Wed, 13 Dec 2006, Greg KH wrote:
Numerous kernel developers feel that loading non-GPL drivers into the
kernel violates the license of the kernel and their copyright. Because
of this, a one year notice for everyone to address any non-GPL
compatible modules has been
Linus Torvalds wrote:
On Wed, 13 Dec 2006, Greg KH wrote:
Numerous kernel developers feel that loading non-GPL drivers into the
kernel violates the license of the kernel and their copyright. Because
of this, a one year notice for everyone to address any non-GPL
compatible modules has been
Greg KH wrote:
On Mon, Dec 04, 2006 at 12:12:06AM +0100, Bj?rn Steinbrink wrote:
On 2006.12.03 14:39:44 -0800, Martin J. Bligh wrote:
This PC has 1 ethernet interface, an e1000. Ubuntu Dapper.
On 2.6.14, my e1000 interface appears as eth0.
On 2.6.15 to 2.6.18, my e1000 interface appears
Greg KH wrote:
On Mon, Dec 04, 2006 at 12:12:06AM +0100, Bj?rn Steinbrink wrote:
On 2006.12.03 14:39:44 -0800, Martin J. Bligh wrote:
This PC has 1 ethernet interface, an e1000. Ubuntu Dapper.
On 2.6.14, my e1000 interface appears as eth0.
On 2.6.15 to 2.6.18, my e1000 interface appears
This PC has 1 ethernet interface, an e1000. Ubuntu Dapper.
On 2.6.14, my e1000 interface appears as eth0.
On 2.6.15 to 2.6.18, my e1000 interface appears as eth1.
In both cases, there are no other ethX interfaces listed in
"ifconfig -a". There are no modules involved, just a static
kernel
This PC has 1 ethernet interface, an e1000. Ubuntu Dapper.
On 2.6.14, my e1000 interface appears as eth0.
On 2.6.15 to 2.6.18, my e1000 interface appears as eth1.
In both cases, there are no other ethX interfaces listed in
ifconfig -a. There are no modules involved, just a static
kernel build.
The traces are a bit confusing, but I don't actually see anything wrong
there. The machine has used up all swap, has used up all memory and has
correctly gone and killed things. After that, there's free memory again.
Yeah, it's just a bit odd that it's always in the IO path. Makes me
suspect
On 2.6.18-rc7 and later during LTP:
http://test.kernel.org/abat/48393/debug/console.log
oom-killer: gfp_mask=0x201d2, order=0
Call Trace:
[] out_of_memory+0x33/0x220
[] __alloc_pages+0x23a/0x2c3
[] __do_page_cache_readahead+0x99/0x212
[] sync_page+0x0/0x45
[] io_schedule+0x28/0x33
[]
On 2.6.18-rc7 and later during LTP:
http://test.kernel.org/abat/48393/debug/console.log
oom-killer: gfp_mask=0x201d2, order=0
Call Trace:
[802638cb] out_of_memory+0x33/0x220
[80265374] __alloc_pages+0x23a/0x2c3
[802667d2] __do_page_cache_readahead+0x99/0x212
The traces are a bit confusing, but I don't actually see anything wrong
there. The machine has used up all swap, has used up all memory and has
correctly gone and killed things. After that, there's free memory again.
Yeah, it's just a bit odd that it's always in the IO path. Makes me
suspect
Christian Krafft wrote:
On Wed, 15 Nov 2006 16:57:56 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
On Thu, 16 Nov 2006, KAMEZAWA Hiroyuki wrote:
But there is no memory on the node. Does the zonelist contain the zones of
the node without memory or not? We simply fall back each
Christian Krafft wrote:
On Wed, 15 Nov 2006 16:57:56 -0800 (PST)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Thu, 16 Nov 2006, KAMEZAWA Hiroyuki wrote:
But there is no memory on the node. Does the zonelist contain the zones of
the node without memory or not? We simply fall back each
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/
>
> (kernel.org propagation is slow. There's a temp copy at
> http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-mm2.bz2)
>
>
>
> - Added Andi's x86_64 tree, as separate patches
>
> - Added a driver for
>> >> CONFIG_NUMA was meant to (and did at one point) support both NUMA and flat
>> >> machines. This is essential in order for the distros to support it - same
>> >> will go for sparsemem.
>> >
>> > That's a different issue. The current code works if you boot a NUMA=y
>> > SPARSEMEM=y machine
CONFIG_NUMA was meant to (and did at one point) support both NUMA and flat
machines. This is essential in order for the distros to support it - same
will go for sparsemem.
That's a different issue. The current code works if you boot a NUMA=y
SPARSEMEM=y machine with a single node.
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13/2.6.13-mm2/
(kernel.org propagation is slow. There's a temp copy at
http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-mm2.bz2)
- Added Andi's x86_64 tree, as separate patches
- Added a driver for TI acx1xx
--On Wednesday, September 07, 2005 11:27:54 -0700 Dave Hansen <[EMAIL
PROTECTED]> wrote:
> On Wed, 2005-09-07 at 11:22 -0700, Martin J. Bligh wrote:
>> CONFIG_NUMA was meant to (and did at one point) support both NUMA and flat
>> machines. This is essential in order for t
--On Wednesday, September 07, 2005 10:28:36 -0700 Dave Hansen <[EMAIL
PROTECTED]> wrote:
> On Tue, 2005-09-06 at 12:56 +0900, Magnus Damm wrote:
>> This patch for 2.6.13-git5 fixes single node sparsemem support. In the case
>> when multiple nodes are used, setup_memory() in
>> > Anticipatory prefaulting raises the highest fault rate obtainable
>> > three-fold
>> > through gang scheduling faults but may allocate some pages to a task that
>> > are
>> > not needed.
>>
>> IIRC that costed more than it saved, at least for forky workloads like a
>> kernel compile -
> Anticipatory prefaulting raises the highest fault rate obtainable three-fold
> through gang scheduling faults but may allocate some pages to a task that are
> not needed.
IIRC that costed more than it saved, at least for forky workloads like a
kernel compile - extra cost in zap_pte_range etc.
Anticipatory prefaulting raises the highest fault rate obtainable three-fold
through gang scheduling faults but may allocate some pages to a task that are
not needed.
IIRC that costed more than it saved, at least for forky workloads like a
kernel compile - extra cost in zap_pte_range etc. If
Anticipatory prefaulting raises the highest fault rate obtainable
three-fold
through gang scheduling faults but may allocate some pages to a task that
are
not needed.
IIRC that costed more than it saved, at least for forky workloads like a
kernel compile - extra cost in
--On Wednesday, September 07, 2005 10:28:36 -0700 Dave Hansen [EMAIL
PROTECTED] wrote:
On Tue, 2005-09-06 at 12:56 +0900, Magnus Damm wrote:
This patch for 2.6.13-git5 fixes single node sparsemem support. In the case
when multiple nodes are used, setup_memory() in arch/i386/mm/discontig.c
--On Wednesday, September 07, 2005 11:27:54 -0700 Dave Hansen [EMAIL
PROTECTED] wrote:
On Wed, 2005-09-07 at 11:22 -0700, Martin J. Bligh wrote:
CONFIG_NUMA was meant to (and did at one point) support both NUMA and flat
machines. This is essential in order for the distros to support
Breaks build on PPC64
Lots of this:
In file included from fs/xfs/linux-2.6/xfs_linux.h:57,
from fs/xfs/xfs.h:35,
from fs/xfs/xfs_rtalloc.c:37:
fs/xfs/xfs_arch.h:55:21: warning: "__LITTLE_ENDIAN" is not defined
In file included from fs/xfs/xfs_rtalloc.c:50:
Breaks build on PPC64
Lots of this:
In file included from fs/xfs/linux-2.6/xfs_linux.h:57,
from fs/xfs/xfs.h:35,
from fs/xfs/xfs_rtalloc.c:37:
fs/xfs/xfs_arch.h:55:21: warning: __LITTLE_ENDIAN is not defined
In file included from fs/xfs/xfs_rtalloc.c:50:
>> They're incompatible, but you could be left to choose one or the other
>> via config option.
>
> Wouldn't need config option: there's /proc/sys/kernel/randomize_va_space
> for the whole running system, compatibility check on the ELFs run, and
> the infinite stack rlimit: enough ways to
--Hugh Dickins <[EMAIL PROTECTED]> wrote (on Wednesday, August 31, 2005
14:42:38 +0100):
> On Wed, 31 Aug 2005, Arjan van de Ven wrote:
>> On Wed, 2005-08-31 at 12:44 +0100, Hugh Dickins wrote:
>> > I was going to say, doesn't randomize_va_space take away the rest of
>> > the point? But no, it
--Hugh Dickins [EMAIL PROTECTED] wrote (on Wednesday, August 31, 2005
14:42:38 +0100):
On Wed, 31 Aug 2005, Arjan van de Ven wrote:
On Wed, 2005-08-31 at 12:44 +0100, Hugh Dickins wrote:
I was going to say, doesn't randomize_va_space take away the rest of
the point? But no, it appears
They're incompatible, but you could be left to choose one or the other
via config option.
Wouldn't need config option: there's /proc/sys/kernel/randomize_va_space
for the whole running system, compatibility check on the ELFs run, and
the infinite stack rlimit: enough ways to suppress
> -scheduler-cache-hot-autodetect.patch
>
> Mabe Martin's machine crash
That machine now boots again with this -mm release. Darren and/or I
will continue trying to figure out what went wrong with this.
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
-scheduler-cache-hot-autodetect.patch
Mabe Martin's machine crash
That machine now boots again with this -mm release. Darren and/or I
will continue trying to figure out what went wrong with this.
M.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
--Andrew Morton <[EMAIL PROTECTED]> wrote (on Friday, August 19, 2005 04:33:31
-0700):
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
>
> - Lots of fixes, updates and cleanups all over the place.
>
> - If you have the right debugging options set,
--Andrew Morton [EMAIL PROTECTED] wrote (on Friday, August 19, 2005 04:33:31
-0700):
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm1/
- Lots of fixes, updates and cleanups all over the place.
- If you have the right debugging options set, this
1 - 100 of 283 matches
Mail list logo
