Re: [patch -mm] i386: use pte_update_defer in ptep_test_and_clear_{dirty,young}

2007-04-16 Thread David Rientjes
On Mon, 16 Apr 2007, Hugh Dickins wrote: When, as now, core mm people make some change, failing to take your case into account. That's exactly what happened here: include/asm-i386/pgtable.h is advertising both __HAVE_ARCH_PTEP_TEST_AND_CLEAR_{DIRTY,YOUNG} without actually having them. No

Re: [patch -mm] i386: use pte_update_defer in ptep_test_and_clear_{dirty,young}

2007-04-16 Thread David Rientjes
/smaps for approximating memory footprint, we'll end up saving TLB flushes because the granularity with which that measurement is taken is usually very fine. Acked-by: David Rientjes [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

[patch -mm] cpusets: allow TIF_MEMDIE threads to allocate anywhere

2007-04-23 Thread David Rientjes
-off-by: David Rientjes [EMAIL PROTECTED] --- kernel/cpuset.c | 22 -- 1 files changed, 20 insertions(+), 2 deletions(-) diff --git a/kernel/cpuset.c b/kernel/cpuset.c --- a/kernel/cpuset.c +++ b/kernel/cpuset.c @@ -2351,6 +2351,8 @@ static const struct cpuset

[patch -mm v2] cpusets: allow TIF_MEMDIE threads to allocate anywhere

2007-04-23 Thread David Rientjes
-off-by: David Rientjes [EMAIL PROTECTED] --- kernel/cpuset.c | 22 -- 1 files changed, 20 insertions(+), 2 deletions(-) diff --git a/kernel/cpuset.c b/kernel/cpuset.c --- a/kernel/cpuset.c +++ b/kernel/cpuset.c @@ -2351,6 +2351,8 @@ static const struct cpuset

[patch] oom: kill all threads that share mm with killed task

2007-04-23 Thread David Rientjes
oom_kill_task() calls __oom_kill_task() to OOM kill a selected task. When finding other threads that share an mm with that task, we need to kill those individual threads and not the same one. Cc: Andi Kleen [EMAIL PROTECTED] Cc: Christoph Lameter [EMAIL PROTECTED] Signed-off-by: David Rientjes

Re: [patch] oom: kill all threads that share mm with killed task

2007-04-24 Thread David Rientjes
On Mon, 23 Apr 2007, Christoph Lameter wrote: Obvious fix. It was broken by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f2a2a7108aa0039ba7a5fe7a0d2ecef2219a7584 Dec 7. So its in 2.6.20 and later. Candiate for stable? I agree it's obvious enough that it

[patch -mm] smaps: flush tlb only once for each vma

2007-02-13 Thread David Rientjes
PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- fs/proc/task_mmu.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -276,7 +276,6 @@ static void clear_refs_one_pmd(struct

[patch -mm 1/2] i386: add ptep_test_and_clear_{dirty,young}

2007-03-25 Thread David Rientjes
. The overall net effect to current users of ptep_clear_flush_{dirty,young} is that we introduce an additional branch. Cc: Hugh Dickins [EMAIL PROTECTED] Cc: Ingo Molnar [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- include/asm-i386/pgtable.h | 25

[patch -mm 2/2] smaps: use ptep_test_and_clear_young

2007-03-25 Thread David Rientjes
Use arch-specified ptep_test_and_clear_young() to clear the pte accessed bits for /proc/pid/clear_refs. This avoids a race condition if a pte is modified between pte_mkold() and set_pte_at(). Cc: Hugh Dickins [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- fs/proc

Re: [patch -mm 1/2] i386: add ptep_test_and_clear_{dirty,young}

2007-03-25 Thread David Rientjes
On Sun, 25 Mar 2007, Zachary Amsden wrote: If you actually clear the bit, you need to: + pte_update_defer(vma-vm_mm, addr, ptep); The reason is, when updating PTEs, the hypervisor must be notified. Using atomic operations to do this is fine for all hypervisors I am aware of.

[patch -mm] i386: use pte_update_defer in ptep_test_and_clear_{dirty,young}

2007-03-25 Thread David Rientjes
[EMAIL PROTECTED] Cc: Hugh Dickins [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- include/asm-i386/pgtable.h | 26 ++ 1 files changed, 14 insertions(+), 12 deletions(-) diff --git a/include/asm-i386/pgtable.h b/include/asm-i386/pgtable.h --- a/include

[patch] usb: call bdev_read_only() only on CONFIG_BLOCK

2007-03-27 Thread David Rientjes
bdev_read_only() is only defined on CONFIG_BLOCK so we make sure not to call it unless we have it. A new static inline function, is_inode_read_only(), is invoked to call bdev_read_only() on CONFIG_BLOCK and return zero otherwise. Cc: Alan Stern [EMAIL PROTECTED] Signed-off-by: David Rientjes

Re: [PATCH 11/13] maps#2: Make /proc/pid/clear_refs option under CONFIG_EMBEDDED

2007-04-06 Thread David Rientjes
-by: Matt Mackall [EMAIL PROTECTED] Acked-by: David Rientjes [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org

[patch -mm 2/7] x86_64: split remaining fake nodes equally

2007-03-01 Thread David Rientjes
. This is beneficial for systems where the exact size of RAM is unknown or not necessarily relevant, but the granularity with which nodes shall be allocated is known. Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- Documentation/x86_64/boot-options.txt |4

[patch -mm 1/7] x86_64: configurable fake numa node sizes

2007-03-01 Thread David Rientjes
it eliminates the overhead associated with scanning the zonelists of many smaller full nodes on page_alloc(). Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- Documentation/x86_64/boot-options.txt |8 +- arch/x86_64/mm/numa.c | 255

[patch -mm 5/7] x86_64: disable alien cache for fake numa

2007-03-01 Thread David Rientjes
Disables using alien cache for slab when NUMA emulation is being used. Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: Paul Menage [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- arch/x86_64/mm/numa.c |2 ++ mm/slab.c |2 +- 2 files changed, 3 insertions

[patch -mm 3/7] x86_64: fixed size remaining fake nodes

2007-03-01 Thread David Rientjes
] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- Documentation/x86_64/boot-options.txt | 14 ++--- arch/x86_64/mm/numa.c | 47 ++--- 2 files changed, 46 insertions(+), 15 deletions(-) diff --git a/Documentation/x86_64/boot-options.txt b

[patch -mm 4/7] x86_64: map fake nodes to real nodes

2007-03-01 Thread David Rientjes
() is modified to use the physical node that corresponds to the fake node for measurement. Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: Rohit Seth [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- arch/x86_64/mm/k8topology.c | 23 +--- arch/x86_64/mm/numa.c | 113

[patch -mm 7/7] x86_64: fake numa for cpusets document

2007-03-01 Thread David Rientjes
Create a document to explain how to use numa=fake in conjunction with cpusets for coarse memory resource management. An attempt to get more awareness and testing for this feature. Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- Documentation/x86_64/fake-numa

[patch -mm 6/7] x86_64: export physnode mapping to userspace

2007-03-01 Thread David Rientjes
Exports the physical NUMA node to fake NUMA node mapping to user-space via sysfs. The information is now accessible via the 'physnode' file. Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: Rohit Seth [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- drivers/base/node.c

[patch -mm] x86_64: fake numa cmdline flag fix

2007-03-02 Thread David Rientjes
Make sure we only reference 'cmdline' on CONFIG_NUMA_EMU. Signed-off-by: David Rientjes [EMAIL PROTECTED] --- arch/x86_64/mm/numa.c | 16 +++- 1 files changed, 11 insertions(+), 5 deletions(-) diff --git a/arch/x86_64/mm/numa.c b/arch/x86_64/mm/numa.c --- a/arch/x86_64/mm/numa.c

[2.6.21-rc3] cpufreq: p4-clockmod.c compilation error

2007-03-06 Thread David Rientjes
arch/x86_64/kernel/built-in.o: In function `cpufreq_p4_verify':p4-clockmod.c:(.text.cpufreq_p4_verify+0x8): undefined reference to `cpufreq_frequency_table_verify' arch/x86_64/kernel/built-in.o: In function `cpufreq_p4_cpu_exit':p4-clockmod.c:(.text.cpufreq_p4_cpu_exit+0x8): undefined

Re: [2.6.21-rc3] cpufreq: p4-clockmod.c compilation error

2007-03-06 Thread David Rientjes
+ bool config CPU_FREQ_DEBUG bool Enable CPUfreq debugging That did the trick, thanks. Acked-by: David Rientjes [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http

Re: [PATCH 11/13] maps: Make /proc/pid/clear_refs option under CONFIG_EMBEDDED

2007-04-04 Thread David Rientjes
-by: Matt Mackall [EMAIL PROTECTED] Acked-by: David Rientjes [EMAIL PROTECTED] Althought /proc/pid/clear_refs isn't actually useful without smaps as well, so you could make it depend on CONFIG_PROC_SMAPS. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

Re: [PATCH 2/4] [-mm patch] Add nodemask_t's size and NR_FREE_PAGES's value to vmcoreinfo_data.

2007-09-13 Thread David Rientjes
On Fri, 14 Sep 2007, Ken'ichi Ohmichi wrote: diff -rpuN a/include/linux/kexec.h b/include/linux/kexec.h --- a/include/linux/kexec.h 2007-09-10 23:28:42.0 +0900 +++ b/include/linux/kexec.h 2007-09-10 23:29:52.0 +0900 @@ -132,11 +132,16 @@ unsigned long

Re: [03/17] is_vmalloc_addr(): Check if an address is within the vmalloc boundaries

2007-09-19 Thread David Rientjes
On Tue, 18 Sep 2007, Christoph Lameter wrote: Index: linux-2.6/include/linux/mm.h === --- linux-2.6.orig/include/linux/mm.h 2007-09-17 21:46:06.0 -0700 +++ linux-2.6/include/linux/mm.h 2007-09-17 23:56:54.0

Re: [03/17] is_vmalloc_addr(): Check if an address is within the vmalloc boundaries

2007-09-19 Thread David Rientjes
On Wed, 19 Sep 2007, Anton Altaparmakov wrote: Index: linux-2.6/include/linux/mm.h === --- linux-2.6.orig/include/linux/mm.h 2007-09-17 21:46:06.0 -0700 +++ linux-2.6/include/linux/mm.h 2007-09-17

Re: [03/17] is_vmalloc_addr(): Check if an address is within the vmalloc boundaries

2007-09-19 Thread David Rientjes
On Wed, 19 Sep 2007, Anton Altaparmakov wrote: Although it may cause a problem as highmem.h also includes mm.h so a bit of trickery may be needed to get it to compile... I suspect that is_vmalloc_addr() should not be in linux/mm.h at all and should be in linux/vmalloc.h instead and

Re: [PATCH 5/4] [-mm patch] Rename macros returning the size.

2007-09-20 Thread David Rientjes
it need not be used exclusively for typedefs. This idea is David Rientjes's. http://www.ussg.iu.edu/hypermail/linux/kernel/0709.1/1964.html Thanks Ken'ichi Ohmichi --- Signed-off-by: David Rientjes [EMAIL PROTECTED] Hmm, I think adding a s-o-b line for David here isn't quite

Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks

2007-12-01 Thread David Rientjes
The checked auto variable isn't doing anything in check_hung_uninterruptible_tasks(). Signed-off-by: David Rientjes [EMAIL PROTECTED] --- kernel/softlockup.c |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/kernel/softlockup.c b/kernel/softlockup.c --- a/kernel

Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks

2007-12-01 Thread David Rientjes
On Sat, 1 Dec 2007, Ingo Molnar wrote: this patch extends the soft-lockup detector to automatically detect hung TASK_UNINTERRUPTIBLE tasks. Such hung tasks are printed the following way: Wouldn't a natural extension of this feature be to mark these hung TASK_UNINTERRUPTIBLE tasks with a

Re: [feature] automatically detect hung TASK_UNINTERRUPTIBLE tasks

2007-12-02 Thread David Rientjes
On Sun, 2 Dec 2007, Ingo Oeser wrote: maybe, but we'd have to see how often this gets triggered. An OOM is something that could happen in any overloaded system - while a hung task is likely due to a kernel bug. What about a client using hard mounted NFS shares here? That shouldn't be

Re: [PATCH] Fake NUMA emulation for PowerPC

2007-12-07 Thread David Rientjes
On Sat, 8 Dec 2007, Balbir Singh wrote: You're going to want to distribute the cpu's based on how they match up physically with the actual platform that you're running on. x86_64 does Could you explain this better, how does it match up CPU's with fake NUMA memory? Is there some

Re: [PATCH] Fake NUMA emulation for PowerPC

2007-12-07 Thread David Rientjes
On Sat, 8 Dec 2007, Balbir Singh wrote: Yes, they all appear on node 0. We could have tweaks to distribute CPU's as well. You're going to want to distribute the cpu's based on how they match up physically with the actual platform that you're running on. x86_64 does this already and it

Re: [PATCH] Fake NUMA emulation for PowerPC

2007-12-07 Thread David Rientjes
On Sat, 8 Dec 2007, Balbir Singh wrote: To be able to test the memory controller under NUMA, I use fake NUMA nodes. x86-64 has a similar feature, the code I have here is the simplest I could come up with for PowerPC. Magnus Damm had patches from over a year ago that, I believe, made much of

Re: [PATCH] Fake NUMA emulation for PowerPC

2007-12-07 Thread David Rientjes
On Fri, 7 Dec 2007, Olof Johansson wrote: Comments are as always welcome! Care to explain what this is useful for? (Not saying it's a stupid idea, just wondering what the reason for doing it is). Fake NUMA has always been useful for testing NUMA code without having to have a wide range

[patch 2/2] cpusets: add interleave_over_allowed option

2007-10-25 Thread David Rientjes
policy is updated to reflect the changes for all attached tasks when this option is set. Cc: Andi Kleen [EMAIL PROTECTED] Cc: Paul Jackson [EMAIL PROTECTED] Cc: Christoph Lameter [EMAIL PROTECTED] Cc: Lee Schermerhorn [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- Documentation

[patch 1/2] cpusets: extract mmarray loading from update_nodemask

2007-10-25 Thread David Rientjes
. Cc: Andi Kleen [EMAIL PROTECTED] Cc: Paul Jackson [EMAIL PROTECTED] Cc: Christoph Lameter [EMAIL PROTECTED] Cc: Lee Schermerhorn [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- kernel/cpuset.c | 130 ++- 1 files changed, 81

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-25 Thread David Rientjes
On Thu, 25 Oct 2007, Christoph Lameter wrote: More interactions between cpusets and memory policies. We have to be careful here to keep clean semantics. I agree. Isnt it a bit surprising for an application that has set up a custom MPOL_INTERLEAVE policy if the nodes suddenly change

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-25 Thread David Rientjes
On Thu, 25 Oct 2007, Paul Jackson wrote: Can we call this memory_spread_user instead, or something else matching memory_spread_* ? Sounds better. I was hoping somebody was going to come forward with an alternative that sounded better than interleave_over_allowed. How about

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-25 Thread David Rientjes
On Thu, 25 Oct 2007, Paul Jackson wrote: David - could you describe the real world situation in which you are finding that this new 'interleave_over_allowed' option, aka 'memory_spread_user', is useful? I'm not always opposed to special case solutions; but they do usually require special

[patch 2/3] mempolicy: mpol_rebind_policy cleanup

2007-10-25 Thread David Rientjes
Jackson [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- mm/mempolicy.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -1741,14 +1741,12 @@ static void mpol_rebind_policy

[patch 1/3] cpusets: extract mmarray loading from update_nodemask

2007-10-25 Thread David Rientjes
. Cc: Andi Kleen [EMAIL PROTECTED] Cc: Paul Jackson [EMAIL PROTECTED] Cc: Christoph Lameter [EMAIL PROTECTED] Cc: Lee Schermerhorn [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- kernel/cpuset.c | 130 ++- 1 files changed, 81

[patch 3/3] cpusets: add memory_spread_user option

2007-10-25 Thread David Rientjes
is updated to reflect the changes for all attached tasks when this option is set. Cc: Andi Kleen [EMAIL PROTECTED] Cc: Paul Jackson [EMAIL PROTECTED] Cc: Christoph Lameter [EMAIL PROTECTED] Cc: Lee Schermerhorn [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- Documentation

[patch 4/3] cpusets: memory_spread_user interleaves over all mems_allowed

2007-10-25 Thread David Rientjes
Lameter [EMAIL PROTECTED] Cc: Lee Schermerhorn [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- mm/mempolicy.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/mempolicy.c b/mm/mempolicy.c --- a/mm/mempolicy.c +++ b/mm/mempolicy.c @@ -1740,7 +1740,7

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-25 Thread David Rientjes
On Thu, 25 Oct 2007, Paul Jackson wrote: Are you seeing this in a real world situation? Can you describe the situation? I don't mean just describing how it looks to this kernel code, but what is going on in the system, what sort of job mix or applications, what kind of users, ... In short,

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-25 Thread David Rientjes
On Thu, 25 Oct 2007, Paul Jackson wrote: The user space man pages for set_mempolicy(2) are now even more behind the curve, by not mentioning that MPOL_INTERLEAVE's mask might mean nothing, if (1) in a cpuset marked memory_spread_user, (2) after the cpuset has changed 'mems'. Yeah. They

Re: [PATCH] De-constify sched.h

2007-10-26 Thread David Rientjes
On Fri, 26 Oct 2007, Alexey Dobriyan wrote: 2) There is no such thing as const task_struct. Anyone who think otherwise deserves compiler warning. A 'const struct task_struct *' can be used as an annotation to mean that no member of the struct is modified through that pointer, so it's

Re: [patch 3/3] cpusets: add memory_spread_user option

2007-10-26 Thread David Rientjes
On Thu, 25 Oct 2007, Paul Jackson wrote: I'm figuring that when someone looks at the cpuset flag: memory_spread_user they will expect that turning it on will cause user space memory to be spread over the nodes of the cpuset. Sure makes sense that it would mean that. But, for

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-26 Thread David Rientjes
On Fri, 26 Oct 2007, Lee Schermerhorn wrote: That's what my cpuset-independent interleave patch does. David doesn't like the null node mask interface because it doesn't work with libnuma. I plan to fix that, but I'm chasing other issues. I should get back to the mempol work after today.

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-26 Thread David Rientjes
On Fri, 26 Oct 2007, Lee Schermerhorn wrote: Actually, my patch doesn't change the set_mempolicy() API at all, it just co-opts a currently unused/illegal value for the nodemask to indicate all allowed nodes. Again, I need to provide a libnuma API to request this. Soon come, mon... If

Re: [patch 3/3] cpusets: add memory_spread_user option

2007-10-26 Thread David Rientjes
On Fri, 26 Oct 2007, Paul Jackson wrote: 1) If you want the current behaviour, where set_mempolicy(MPOL_INTERLEAVE) calls mean what they say, and cpusets tries as best it can (imperfectly) to honor those memory policy calls, even in the face of changing cpusets, then leave

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-26 Thread David Rientjes
On Fri, 26 Oct 2007, Paul Jackson wrote: Without at least this sort of change to MPOL_INTERLEAVE nodemasks, allowing either empty nodemasks (Lee's proposal) or extending them outside the current cpuset (what I'm cooking up now), there is no way for a task that is currently confined to a

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-26 Thread David Rientjes
On Fri, 26 Oct 2007, Christoph Lameter wrote: We would need two fields in the policy structure 1. The specified nodemask (generally ignored) What I've called pol-passed_nodemask. 2. The effective nodemask (specified cpuset_mems_allowed) Which is pol-v.nodes. If we have these two

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-26 Thread David Rientjes
On Fri, 26 Oct 2007, Christoph Lameter wrote: Well, passing a single node to set_mempolicy() for MPOL_INTERLEAVE doesn't make a whole lot of sense in the first place. I prefer your solution of allowing set_mempolicy(MPOL_INTERLEAVE, NODE_MASK_ALL) to mean interleave me over everything

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-26 Thread David Rientjes
On Fri, 26 Oct 2007, Lee Schermerhorn wrote: You don't need to save the entire mask--just note that NODE_MASK_ALL was passed--like with my internal MPOL_CONTEXT flag. This would involve special casing NODE_MASK_ALL in the error checking, as currently set_mempolicy() complains loudly if you

Re: [PATCH 2/12] maps4: From: Dave Hansen [EMAIL PROTECTED]

2007-10-26 Thread David Rientjes
On Fri, 26 Oct 2007, Matt Mackall wrote: The following replaces the earlier patches sent. It should address David Rientjes's comments, and has been compile tested on all the architectures that it touches, save for parisc. Looks good, thanks. - To unsubscribe from this list: send the line

Re: [PATCH 6/12] maps4: simplify interdependence of maps and smaps

2007-10-26 Thread David Rientjes
On Fri, 26 Oct 2007, Matt Mackall wrote: From: Matt Mackall [EMAIL PROTECTED] This pulls the shared map display code out of show_map and puts it in show_smap where it belongs. Signed-off-by: Matt Mackall [EMAIL PROTECTED] Cc: Jeremy Fitzhardinge [EMAIL PROTECTED] Cc: David Rientjes

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-26 Thread David Rientjes
On Fri, 26 Oct 2007, Lee Schermerhorn wrote: So, you pass the subset, you don't set the flag to indicate you want interleaving over all available. You must be thinking of some other use for saving the subset mask that I'm not seeing here. Maybe restoring to the exact nodes requested if

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-27 Thread David Rientjes
On Fri, 26 Oct 2007, Paul Jackson wrote: Choice A: as it does today, the second node in the tasks cpuset or it could mean Choice B: the fourth node in the cpuset, if available, just as it did in the case above involving a cpuset on nodes 10 and 11. Thanks for describing

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-27 Thread David Rientjes
On Fri, 26 Oct 2007, Paul Jackson wrote: Yes. We should default to Choice B. Add an option MPOL_MF_RELATIVE to enable that functionality? A new version of numactl can then enable that by default for newer applications. I'm confused. If B is the default, then we don't need a flag to

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-27 Thread David Rientjes
On Fri, 26 Oct 2007, David Rientjes wrote: Hacking and requiring an updated version of libnuma to allow empty nodemasks to be passed is a poor solution; if mempolicy's are supposed to be independent from cpusets, then what semantics does an empty nodemask actually imply when using

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-28 Thread David Rientjes
On Sat, 27 Oct 2007, Paul Jackson wrote: but I actually would recommend against any flag to effect Choice A. It's simply going to be too complex to describe and is going to be a headache to code and support. While I am sorely tempted to agree entirely with this, I suspect that

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-28 Thread David Rientjes
On Sun, 28 Oct 2007, Paul Jackson wrote: The Linux documentation is not a legal contract. Anytime we change the actual behaviour of the code, we have to ask ourselves what will be the impact of that change on existing users and usages. The burden is on us to minimize breaking things (by

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-28 Thread David Rientjes
On Sun, 28 Oct 2007, Paul Jackson wrote: And, unless someone in the know tells us otherwise, I have to assume that this could break them. Now, the odds are that they simply don't run that solution stack on any system making active use of cpusets, so the odds are this would be no problem for

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-29 Thread David Rientjes
On Sun, 28 Oct 2007, Paul Jackson wrote: If we can't identify any applications that would be broken by this, what's the difference in simply implementing Choice B and then, if we hear complaints, add your hack to revert back to Choice A behavior based on the get_mempolicy() call you

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-30 Thread David Rientjes
On Mon, 29 Oct 2007, Paul Jackson wrote: Policies such as MPOL_INTERLEAVE always get AND'd with pol-cpuset_mems_allowed. Not AND'd - Folded, as in bitmap_remap(). If that yields numa_no_nodes, MPOL_DEFAULT is used instead. Not an issue with Folding. Policies such

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-30 Thread David Rientjes
On Mon, 29 Oct 2007, Lee Schermerhorn wrote: And even when the intent is to preserve the cpuset relative positions of the nodes in the nodemask, this really only makes sense if the original and modified cpusets have the same physical topology w/rt multi-level NUMA interconnects. This is

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-30 Thread David Rientjes
On Mon, 29 Oct 2007, Paul Jackson wrote: Blind siding users with a unilateral change like this will leave orphaned bits gasping in agony on the computer room floor. It can sometimes takes months of elapsed time and hundreds of hours of various peoples time across a dozen departments in three

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-30 Thread David Rientjes
On Mon, 29 Oct 2007, Paul Jackson wrote: But in any case, we (the kernel) are just providing the mechanisms. If they don't fit ones needs, don't use them ;). The kernel is providing the mechanism to interleave over a set of nodes or prefer a single node for allocations, but it also provides

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-30 Thread David Rientjes
On Tue, 30 Oct 2007, Paul Jackson wrote: We've already got two Choices, one released and one in the oven. Is there an actual, real world situation, motivating this third Choice? Let's put Choice C into the lower oven, then. Of course there's actual and real world examples of this, because

Re: [patch 2/2] cpusets: add interleave_over_allowed option

2007-10-30 Thread David Rientjes
On Tue, 30 Oct 2007, Paul Jackson wrote: Those applications that currently rely on the remapping are going to be broken anyway because they are unknowingly receiving different nodes than they intended, this is the objection to remapping that Lee agreed with. No, they may or may not be

Re: [2.6 patch] remove __attribute_used__

2007-10-30 Thread David Rientjes
On Wed, 31 Oct 2007, Adrian Bunk wrote: This patch removes the deprecated __attribute_used__. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Acked-by: David Rientjes [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL

Re: [RFC] cpuset relative memory policies - second choice

2007-11-01 Thread David Rientjes
On Wed, 31 Oct 2007, Paul Jackson wrote: David R - is your use of the mbind and *_mempolicy system calls via libnuma, or direct system calls? I hope to be able to use libnuma exclusively once your fix is in place so that the interleaving behaves the way we want while attached to a

Re: sparc compile error

2008-02-10 Thread David Rientjes
On Sun, 10 Feb 2008, Martin Habets wrote: This still gives build errors with CGROUP_MEM_CONT off. Some ifdef-ing will fix that. Please try Linus' latest git that includes 60c12b12 (from yesterday) that fixes this issue. David -- To unsubscribe from this list: send the line

[patch] sparc: fix build

2008-02-10 Thread David Rientjes
use of undefined type 'struct timer_list' Cc: Adrian Bunk [EMAIL PROTECTED] Cc: Robert Reif [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- arch/sparc/kernel/led.c|3 ++- include/linux/memcontrol.h |3 --- 2 files changed, 2 insertions(+), 4

Re: [patch 2/4] mempolicy: support optional mode flags

2008-02-11 Thread David Rientjes
On Mon, 11 Feb 2008, Paul Jackson wrote: If things go as I hope, I expect to spend a couple of days this week reviving my earlier patch RFC that a couple of you on this cc list saw, concerning how nodes are numbered in mempolicy nodemasks. Certainly the work being done in these various

[patch 4/4 v2] mempolicy: update NUMA memory policy documentation

2008-02-11 Thread David Rientjes
[EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- Includes fixes to problems identified by Randy Dunlap. Documentation/filesystems/tmpfs.txt | 11 Documentation/vm/numa_memory_policy.txt | 41 +++ 2 files changed, 47 insertions(+), 5

Re: [patch 1/4] mempolicy: convert MPOL constants to enum

2008-02-11 Thread David Rientjes
On Mon, 11 Feb 2008, Christoph Lameter wrote: The policy member of struct mempolicy is also converted from type short to type unsigned short. A negative policy does not have any legitimate meaning, so it is possible to change its type in preparation for adding optional mode flags later.

Re: [patch 2/4] mempolicy: support optional mode flags

2008-02-11 Thread David Rientjes
On Mon, 11 Feb 2008, Lee Schermerhorn wrote: These patches look good--well, interesting, anyway. I'm off on assignment this week, so I won't get to review in detail, merge and test them until next... If, by interesting, you mean that they give the most power to the user in setting up

Re: [patch 1/4] mempolicy: convert MPOL constants to enum

2008-02-11 Thread David Rientjes
On Mon, 11 Feb 2008, Andi Kleen wrote: The mempolicy mode constants, MPOL_DEFAULT, MPOL_PREFERRED, MPOL_BIND, and MPOL_INTERLEAVE, are better declared as part of an enum for type checking. What type checking? There is none in standard C for enums. Type checking probably isn't the best

[patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag

2008-02-11 Thread David Rientjes
it is now mostly obsoleted. Cc: Paul Jackson [EMAIL PROTECTED] Cc: Christoph Lameter [EMAIL PROTECTED] Cc: Lee Schermerhorn [EMAIL PROTECTED] Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- include/linux/mempolicy.h |4 +- mm/mempolicy.c| 137

[patch 1/4] mempolicy: convert MPOL constants to enum

2008-02-11 Thread David Rientjes
PROTECTED] Cc: Lee Schermerhorn [EMAIL PROTECTED] Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- Applies on top of V3 of Lee Schermerhorn's mempolicy patch posted to LKML on February 8. include/linux/mempolicy.h | 21 +++-- include/linux/shmem_fs.h

Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag

2008-02-11 Thread David Rientjes
. Cc: Paul Jackson [EMAIL PROTECTED] Cc: Christoph Lameter [EMAIL PROTECTED] Cc: Lee Schermerhorn [EMAIL PROTECTED] Cc: Andi Kleen [EMAIL PROTECTED] Cc: KOSAKI Motohiro [EMAIL PROTECTED] Signed-off-by: David Rientjes [EMAIL PROTECTED] --- mm/mempolicy.c | 10 +- 1 files changed, 5

[patch 2/4] mempolicy: support optional mode flags

2008-02-11 Thread David Rientjes
-by: David Rientjes [EMAIL PROTECTED] --- fs/hugetlbfs/inode.c |2 +- include/linux/mempolicy.h | 39 +-- mm/mempolicy.c| 77 ++-- mm/shmem.c| 15 ++-- 4 files changed, 93 insertions(+), 40

[patch 4/4] mempolicy: update NUMA memory policy documentation

2008-02-11 Thread David Rientjes
-by: David Rientjes [EMAIL PROTECTED] --- Documentation/filesystems/tmpfs.txt | 11 Documentation/vm/numa_memory_policy.txt | 41 +++ 2 files changed, 47 insertions(+), 5 deletions(-) diff --git a/Documentation/filesystems/tmpfs.txt b/Documentation/filesystems

Re: [PATCH for 2.6.24][regression fix] Mempolicy: silently restrict nodemask to allowed nodes V3

2008-02-11 Thread David Rientjes
On Tue, 12 Feb 2008, KOSAKI Motohiro wrote: [PATCH] 2.6.24 - mempolicy: silently restrict nodemask to allowed nodes Linus has already merged this patch into his tree, but next time you pass along a contribution to a maintainer the first line should read: From: Lee Schermerhorn [EMAIL

Re: [patch 1/4] mempolicy: convert MPOL constants to enum

2008-02-11 Thread David Rientjes
On Mon, 11 Feb 2008, Christoph Lameter wrote: Then you could follow through with the enum mempolicy thing throughtout. Why not use enum mempolicy in struct mempolicy? Mempolicy flags, as I implemented them in patch 2 in this series, are not integer constants that are enumerated starting at

Re: [patch 2/4] mempolicy: support optional mode flags

2008-02-12 Thread David Rientjes
On Tue, 12 Feb 2008, Lee Schermerhorn wrote: What is the benefit of pulling the flags and mode apart at the user interface, passing them as separate args to mpol_new(), do_* and mpol_shared_policy_init() and then stitching them back together in mpol_new()? Modes passed in via

Re: [patch 1/4] mempolicy: convert MPOL constants to enum

2008-02-12 Thread David Rientjes
On Tue, 12 Feb 2008, Paul Jackson wrote: == If each time I look at some 'flags' field, I have to think of it as a couple of things glued together that I will have to pick apart to use, that's more mental work than seeing those two things explicit and separate, through most of the mempolicy.c

Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag

2008-02-12 Thread David Rientjes
On Tue, 12 Feb 2008, Paul Jackson wrote: I've redone my patchset based on the feedback that I've received Will you be sending that along soon? I was just getting into my review of this patchset, and I suppose it would be better to review the latest and greatest. Lee had some questions

Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag

2008-02-12 Thread David Rientjes
On Tue, 12 Feb 2008, Lee Schermerhorn wrote: Adds another member to struct mempolicy, nodemask_t user_nodemask that stores the the nodemask that the user passed when he or she created the mempolicy via set_mempolicy() or mbind(). When using MPOL_F_STATIC_NODES, which is

Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag

2008-02-12 Thread David Rientjes
On Tue, 12 Feb 2008, David Rientjes wrote: Since we're allowed to remap the node to a different node than the user specified with either syscall, the current behavior is that one node is as good as another. In other words, we're trying to accomodate the mode first by setting pol

Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag

2008-02-12 Thread David Rientjes
On Tue, 12 Feb 2008, Paul Jackson wrote: 1) we've discussed the issue of returning EINVAL for non-empty nodemasks with MPOL_DEFAULT. By removing this restriction, we run the risk of breaking applications if we should ever want to define a semantic to non-empty node mask for MPOL_DEFAULT.

Re: [patch 1/4] mempolicy: convert MPOL constants to enum

2008-02-12 Thread David Rientjes
On Tue, 12 Feb 2008, Paul Jackson wrote: However, once inside the kernel, how we store this flag in struct mempolicy, and how we pass it about between kernel routines, is our choice. We can leave it packed, and unpack and repack it each time we consider the flag and mode bits, or we can

Re: [patch 1/4] mempolicy: convert MPOL constants to enum

2008-02-12 Thread David Rientjes
On Tue, 12 Feb 2008, Paul Jackson wrote: I tend to agree with Lee on this one. If I recall correctly, Christoph said something similar, regarding the change of the 'policy' field of struct mempolicy from a short to an enum. I've already made the change in my patchset as a result of

Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag

2008-02-12 Thread David Rientjes
On Tue, 12 Feb 2008, Lee Schermerhorn wrote: PATCH mempolicy - consolidate mpol_new() error paths Use common error path in mpol_new() for errors that we discover after allocation the new mempolicy structure. Free the mempolicy in the common error path. Signed-off-by: Lee Schermerhorn

Re: [patch 2/4] mempolicy: support optional mode flags

2008-02-12 Thread David Rientjes
On Tue, 12 Feb 2008, Lee Schermerhorn wrote: Hmmm, so 'static' means don't contexutalize--i.e., don't mask off disallowed or memoryless nodes? That means we'll need to skip them in the interleave node calculation in the allocation path. Perhaps your patch already addresses this, but I

Re: [patch 1/4] mempolicy: convert MPOL constants to enum

2008-02-12 Thread David Rientjes
On Tue, 12 Feb 2008, Paul Jackson wrote: Christoph wrote: Good. And remove the enum. It would be better to add some sort of flags field? On the other hand, despite my brilliant (hah!) endorsement of bit field flags in my reply a few minutes ago, I'd settle for (1) removing the enum,

Re: [patch 3/4] mempolicy: add MPOL_F_STATIC_NODES flag

2008-02-13 Thread David Rientjes
On Wed, 13 Feb 2008, Paul Jackson wrote: The infamous unpublished (except to a few) patch I drafted on Christmas (Dec 25, 2007) basically added two new modes for how mempolicy nodemasks were to be resolved: 1) a static, no remap, mode, such as in this present patchset, and 2) a cpuset

  1   2   3   4   5   6   7   8   9   10   >