On Thu, 9 Aug 2012, Mauro Carvalho Chehab wrote:
Yeah, that would work as well, although the code would look uglier.
IMHO, using select/depend is better.
Agreed, I think it should be depends on LEDS_CLASS rather than select
it if there is a hard dependency that cannot be fixed with
On Tue, 5 Feb 2008, Paul Jackson wrote:
But that discussion touched on some other long standing deficiencies
in the way that I had originally glued cpusets and memory policies
together. The current mechanism doesn't handle changing cpusets very
well, especially if the number of nodes in the
On Tue, 5 Feb 2008, Paul Jackson wrote:
Since any of those future patches only add optional modes
with new flags, while preserving current behaviour if you
don't use one of the new flags, therefore the current behavior
has to work as best it can.
There's a subtlety to this issue that
On Tue, 5 Feb 2008, Paul Jackson wrote:
David wrote:
The more alarming result of these remaps is in the MPOL_BIND case, as
we've talked about before. The language in set_mempolicy(2):
You're diving into the middle of a rather involved discussion
we had on the other various patches
On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
The patch I just posted doesn't depend on the numactl changes and seems
quite minimal to me. I think it cleans up the differences between
set_mempolicy() and mbind(), as well. However, some may take exception
to the change in behavior--silently
On Tue, 5 Feb 2008, Jeff Davis wrote:
The interesting thing is the use of total_vm and not the RSS which is used
as
the basis by the OOM killer. I need to read/understand the code a bit more.
RSS makes more sense to me as well.
To me, it makes no sense to count shared memory, because
On Wed, 6 Feb 2008, KOSAKI Motohiro wrote:
Andrea Arcangeli has patches pending which change this to the RSS.
Specifically:
http://marc.info/?l=linux-mmm=119977937126925
I agreed with you that RSS is better :)
but..
on many node numa, per zone rss is more better..
It
On Tue, 5 Feb 2008, Lee Schermerhorn wrote:
Index: Linux/mm/mempolicy.c
===
--- Linux.orig/mm/mempolicy.c 2008-02-05 11:25:17.0 -0500
+++ Linux/mm/mempolicy.c 2008-02-05 16:03:11.0 -0500
@@ -131,7 +131,7 @@
On Wed, 6 Feb 2008, Sven Wegener wrote:
diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs_sync.c
index 948378d..9b57ad3 100644
--- a/net/ipv4/ipvs/ip_vs_sync.c
+++ b/net/ipv4/ipvs/ip_vs_sync.c
@@ -143,6 +143,8 @@ char ip_vs_backup_mcast_ifn[IP_VS_IFNAME_MAXLEN];
/* multicast
3062fc67 introduced far too many build errors for the convenience it
allows. It's not even always necessary to rcu deference mm-mem_cgroup in
the first place, so we'll use it on a case by case basis.
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
include/linux/memcontrol.h | 13
On Fri, 18 Jan 2008, Yinghai Lu wrote:
+#if MAX_NUMNODES 256
+typedef u16 numanode_t;
+#else
+typedef u8 numanode_t;
+#endif
+
#endif /* _LINUX_NUMA_H */
that is wrong, you can not change pxm_to_node_map from int to u8 or u16.
Yeah, NID_INVAL is negative so no unsigned type
On Fri, 18 Jan 2008, Yinghai Lu wrote:
I got
SART: PXM 0 - APIC 0 - Node 255
SART: PXM 0 - APIC 1 - Node 255
SART: PXM 1 - APIC 2 - Node 255
SART: PXM 1 - APIC 3 - Node 255
I assume this is a typo and those proximity mappings are actually from the
SRAT.
SRAT for
On Sat, 19 Jan 2008, Mike Travis wrote:
Yeah, NID_INVAL is negative so no unsigned type will work here,
unfortunately. And that reduces the intended savings of your change since
the smaller type can only be used with a smaller CONFIG_NODES_SHIFT.
Excuse my ignorance but why
On Sat, 19 Jan 2008, Mike Travis wrote:
Excuse my ignorance but why wouldn't this work:
static numanode_t pxm_to_node_map[MAX_PXM_DOMAINS]
= { [0 ... MAX_PXM_DOMAINS - 1] =
NUMA_NO_NODE };
...
int acpi_map_pxm_to_node(int pxm)
{
int node
On Fri, 15 Feb 2008, David Rientjes wrote:
It would be possible to do all of this in both sys_set_mempolicy() and
sys_mbind() by masking off the set of possible modes and checking the
result for being = MPOL_MAX:
if ((mode MPOL_MODE_FLAGS) = MPOL_MAX)
return -EINVAL
On Fri, 15 Feb 2008, Paul Jackson wrote:
So that last line should be:
1,3,5 4-105,7,9
What about this case where one of the relative nodes wraps around to
represent an already set node in the result?
relativemems_allowedresult
On Fri, 15 Feb 2008, Paul Jackson wrote:
I don't think so. It's not possible to detemine if exactly the low
eight bits of the 'policy' short are a valid mode, -however- that
eight is a spurious detail. Remove it.
Sure it is, you can determine if the low MPOL_FLAG_SHIFT bits are a valid
On Fri, 15 Feb 2008, Paul Jackson wrote:
--- 2.6.24-mm1.orig/include/linux/mempolicy.h 2008-02-15 00:11:10.0
-0800
+++ 2.6.24-mm1/include/linux/mempolicy.h 2008-02-15 15:16:16.031031424
-0800
@@ -8,6 +8,14 @@
* Copyright 2003,2004 Andi Kleen SuSE Labs
*/
+/*
+ * The
this as well, for the !CONFIG_SYSFS case.
Cc: Randy Dunlap [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
include/linux/sysfs.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
--- a/include/linux/sysfs.h
On Sat, 16 Feb 2008, Paul Jackson wrote:
Let's say an application has specified some mempolicies
that presume 16 memory nodes, including say a mempolicy that
specified MPOL_F_RELATIVE_NODES (cpuset relative) nodes 12-15.
Then lets say that application is crammed into a cpuset that only
has 8
Change sysfs_remove_bin_file() to have a return value of void in the
!CONFIG_SYSFS case, matching the return value of the same function with
the opposite configuration.
Also moves unnecessary ';' in empty void functions.
Cc: Randy Dunlap [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL
Convert sysfs_remove_bin_file() to have a return type of 'void' for
!CONFIG_SYSFS configurations. Also removes unnecessary colons from empty
void functions.
Cc: Randy Dunlap [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
include/linux/sysfs.h |9 ++---
1 files
obsoleted. The unused vma_mpol_equal() is also removed.
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 | 11 ++-
mm
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 | 19 ++-
include/linux/shmem_fs.h |2 +-
mm/mempolicy.c| 27
PROTECTED].
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 |3 ++-
mm/mempolicy.c| 40
.
An additional member is also added to struct shmem_sb_info to store the
optional mode flags.
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]
---
fs
-by: Paul Jackson [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
---
include/linux/bitmap.h |6 ++
include/linux/cpumask.h | 22 ++-
include
[EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
Documentation/filesystems/tmpfs.txt | 19 +++
Documentation/vm/numa_memory_policy.txt | 54 --
2 files changed, 69 insertions(+), 4 deletions(-)
diff --git a/Documentation/filesystems
On Mon, 25 Feb 2008, Paul Jackson wrote:
+enum {
+ MPOL_DEFAULT,
+ MPOL_PREFERRED,
+ MPOL_BIND,
+ MPOL_INTERLEAVE,
+ MPOL_MAX, /* always last member of enum */
Aren't the values that these constants take part of the
user visible kernel API?
In other words,
On Mon, 25 Feb 2008, Paul Jackson wrote:
Eh ... each bit of added clarity to the code reduces
errors.
Looking around the kernel, it really seems to me to be
a common coding to explicitly spell out enum values
when for some reason they actually matter.
Like most coding mechanisms,
On Tue, 26 Feb 2008, Paul Jackson wrote:
David wrote:
+static nodemask_t mpol_relative_nodemask(const nodemask_t *orig,
+ const nodemask_t *rel)
+{
+ nodemask_t ret;
+ nodemask_t tmp;
Could you avoid needing the nodemask_t 'ret' on the stack,
On Mon, 25 Feb 2008, Paul Jackson wrote:
$ grep mpol_store_user_nodemask mm/mempolicy.c
static inline int mpol_store_user_nodemask(const struct mempolicy *pol)
if (mpol_store_user_nodemask(policy))
if (!mpol_store_user_nodemask(a))
if
On Sat, 7 Jul 2012, Joonsoo Kim wrote:
__alloc_pages_direct_compact has many arguments so invoking it is very costly.
And in almost invoking case, order is 0, so return immediately.
If zero cost is very costly, then this might make sense.
__alloc_pages_direct_compact() is inlined by gcc.
--
pages within it are currently marked as accessed
(referenced).
Cc: Hugh Dickins [EMAIL PROTECTED]
Cc: Paul Mundt [EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
fs/proc/task_mmu.c | 20 +---
1 files changed, 13 insertions
each PTE now invokes a function call.
Cc: Hugh Dickins [EMAIL PROTECTED]
Cc: Paul Mundt [EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
fs/proc/task_mmu.c | 126 ++--
1 files changed, 82
[EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
fs/proc/base.c | 31 +++
fs/proc/task_mmu.c | 36
include/linux/proc_fs.h |1 +
3 files changed, 68
On Tue, 6 Feb 2007, Andrew Morton wrote:
@@ -190,18 +191,20 @@ static int show_map_internal(struct seq_file *m, void
*v, struct mem_size_stats
if (mss)
seq_printf(m,
- Size: %8lu kB\n
- Rss: %8lu kB\n
each PTE now invokes a function call.
Cc: Hugh Dickins [EMAIL PROTECTED]
Cc: Paul Mundt [EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
fs/proc/task_mmu.c | 126 ++--
1 files changed, 82
to indicate how many pages within it are currently marked as accessed
(referenced).
Cc: Hugh Dickins [EMAIL PROTECTED]
Cc: Paul Mundt [EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
fs/proc/task_mmu.c | 20 +---
1 files
]
Cc: Paul Mundt [EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
fs/proc/base.c | 31 +++
fs/proc/task_mmu.c | 37 +
include/linux/proc_fs.h |1 +
3 files
On Wed, 7 Feb 2007, Christoph Lameter wrote:
Clearing reference bits? Ummm... That is a pretty inaccurate measure since
reclaim can remove pages and revert the reference bits. It can never work
reliably.
It's not intended to work precisely, it's intended to give a good estimate
of task
On Thu, 8 Feb 2007, Linus Torvalds wrote:
Same goes for
struct dummy {
int flag:1;
} a_variable;
which could make a_variable.d be either signed or unsigned. In the
absense of an explicit signed or unsigned by the programmer, you
really won't even _know_
On Thu, 8 Feb 2007, Linus Torvalds wrote:
No, making bitfields unsigned is actually usually a good idea. It allows
you to often generate better code, and it actually tends to be what
programmers _expect_. A lot of people seem to be surprised to hear that a
one-bit bitfield actually often
On Thu, 8 Feb 2007, Linus Torvalds wrote:
No it's not.
You just don't understand the C language.
And if you don't understand the C language, you can't say that's what the
int says. It says no such thing.
The C language clearly says that bitfields have implementation-defined
types.
On Thu, 8 Feb 2007, Linus Torvalds wrote:
Even gcc DOES DIFFERENT THINGS! Have you even read the docs?
By default it is treated as signed int but this may be changed by
the -funsigned-bitfields option.
Yes, I read the 4.1.1 docs:
By default, such a bit-field is
On Thu, 8 Feb 2007, Matt Mackall wrote:
I've been looking at a similar refactoring of other code and I think
the way to go is a callback per block-of-PTEs with start and end
pointers. That gets rid of most of the call indirection overhead.
Yes, but only in a limited number of cases
]
Cc: Paul Mundt [EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
fs/proc/task_mmu.c | 69 +++
1 files changed, 42 insertions(+), 27 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc
within it are currently marked as referenced
or accessed.
Cc: Hugh Dickins [EMAIL PROTECTED]
Cc: Paul Mundt [EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
fs/proc/task_mmu.c | 20 +---
1 files changed, 13 insertions(+), 7
Mundt [EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
fs/proc/base.c | 31 +++
fs/proc/task_mmu.c | 37 +
include/linux/proc_fs.h |1 +
3 files changed
Do not clear references when the task_struct's mm is NULL by using
/proc/pid/clear_refs.
Also, use mmap_sem since the mm_struct's VMA's are being iterated in
fs/proc/task_mmu.c.
Reported by Oleg Nesterov [EMAIL PROTECTED].
Signed-off-by: David Rientjes [EMAIL PROTECTED]
---
fs/proc/base.c
On Wed, 31 Oct 2007, Paul Jackson wrote:
The basic reason that I went with an additional per-task modal
state, rather than a modal flag for each mbind, set_mempolicy and
get_mempolicy call was to reduce the likely rate of bugs in user
level C code using this API.
I think it may be more
On Wed, 31 Oct 2007, Paul Jackson wrote:
With the mode bit as in my patch, there are fewer places in the user
code that have to be gotten just right. With your way, each and
every mbind and *_mempolicy call has to be hacked with the new flag
if one is going to use the new nodemask bit
On Thu, 1 Nov 2007, Paul Jackson wrote:
We were discussing libnuma here, not glibc. The system call wrappers
are in glibc. System call wrappers should not be setting optional
flags. They should just make the system call -- do whatever magic it
takes to get the provided arguments into the
On Thu, 1 Nov 2007, Paul Jackson wrote:
A library such as libnuma can set them, yes, but not everyone uses
libnuma. Basically everyone uses the standard C library, glibc, which
has the system call wrappers, but these wrappers should not be setting
optional flags.
I think what would end up
On Sun, 8 Jul 2012, JoonSoo Kim wrote:
__alloc_pages_direct_compact has many arguments so invoking it is very
costly.
And in almost invoking case, order is 0, so return immediately.
If zero cost is very costly, then this might make sense.
__alloc_pages_direct_compact() is inlined
On Mon, 9 Jul 2012, JoonSoo Kim wrote:
diff --git a/mm/slub.c b/mm/slub.c
index 8c691fa..5d41cad 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1324,8 +1324,14 @@ static struct page *allocate_slab(struct
kmem_cache *s, gfp_t flags, int node)
!(s-flags (SLAB_NOTRACK |
-by: Fengguang Wu fengguang...@intel.com
Tested-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: David Rientjes rient...@google.com
---
mm/slub.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1314,13
On Mon, 9 Jul 2012, Wanpeng Li wrote:
From: Wanpeng Li l...@linux.vnet.ibm.com
Code was duplicated in two functions, clean it up.
Signed-off-by: Wanpeng Li liwp.li...@gmail.com
---
mm/hugetlb.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions(-)
Nack, this
On Sat, 7 Jul 2012, Aaro Koskinen wrote:
I couldn't remember whether the canonical marking is sta...@kernel.org
or sta...@vger.kernel.org, so I went looking, and discovered that it
wasn't mentioned in the kernel sources. You can find mention of it in
Greg K-H's blog, but not everyone
Acked-by: Steven Rostedt rost...@goodmis.org
Tested-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: David Rientjes rient...@google.com
---
mm/slub.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
--- a/mm/slub.c
+++ b/mm/slub.c
On Mon, 9 Jul 2012, JoonSoo Kim wrote:
I think __alloc_pages_direct_compact() can't be inlined by gcc,
because it is so big and is invoked two times in __alloc_pages_nodemask().
We could fix that by doing
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c
+++
On Mon, 9 Jul 2012, a...@linux-foundation.org wrote:
From: Joe Perches j...@perches.com
Subject: checkpatch: Add acheck for use of sizeof without parenthesis
Kernel style uses parenthesis around sizeof.
Nack, there's a difference between sizeof *task and
sizeof(struct task_struct). The
On Mon, 9 Jul 2012, Joe Perches wrote:
Huh? Maybe I misunderstand you.
$ cat sizeof.c
#include stdio.h
#include stdlib.h
#include strings.h
struct foo {
int bar[20];
char *baz;
};
int main(int argc, char **argv)
{
struct foo bar;
struct foo *baz;
On Mon, 9 Jul 2012, Joe Perches wrote:
So, nack, don't start enforcing your own coding style and preferences in
checkpatch.pl.
Not just my opinion.
https://lkml.org/lkml/2008/12/23/138
Date: Tue, 23 Dec 2008 10:08:50 -0800
On Mon, 9 Jul 2012, Joe Perches wrote:
CodingStyle already does suggest parenthesis around sizeof
3.1: Spaces
Linux kernel style for use of spaces depends (mostly) on
function-versus-keyword usage. Use a space after (most) keywords. The
notable exceptions are sizeof, typeof, alignof,
On Tue, 10 Jul 2012, Wanpeng Li wrote:
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index c4b85d0..79a0f33 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -696,7 +696,7 @@ static struct inode *hugetlbfs_alloc_inode(struct
super_block *sb)
p =
On Tue, 10 Jul 2012, Wanpeng Li wrote:
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index c4b85d0..79a0f33 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -696,7 +696,7 @@ static struct inode *hugetlbfs_alloc_inode(struct
super_block *sb)
p =
On Mon, 9 Jul 2012, Joe Perches wrote:
I don't really care what style a large block of code
uses. I care that it mostly has the same form.
Same form?? The sizeof operator has two forms depending on whether it's a
unary expression or a type as specified by the standard.
The issue here is
On Mon, 9 Jul 2012, Linus Torvalds wrote:
sizeof without parenthesis is an abomination, and should never be used.
Sure, you don't need to have the parenthesis (except when you do - for
actual types), but it's a parsing oddity.
The sane solution is: just add the f*cking parenthesis, and
On Tue, 10 Jul 2012, Minchan Kim wrote:
So I dunno, this all looks like we have a kernel problem and we're
throwing our problem onto hopelessly ill-equipped users of that kernel?
As you know, this patch isn't for solving regular high-order allocations.
As I wrote down, The problem is that
On Tue, 10 Jul 2012, Arnd Bergmann wrote:
diff --git a/mm/slob.c b/mm/slob.c
index 95d1c7d..51d6a27 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -426,7 +426,7 @@ out:
void *__kmalloc_node(size_t size, gfp_t gfp, int node)
{
unsigned int *m;
- int align =
On Wed, 11 Jul 2012, Minchan Kim wrote:
Should we consider enabling CONFIG_COMPACTION in defconfig? If not, would
I hope so but Mel didn't like it because some users want to have a smallest
kernel if they don't care of high-order allocation.
CONFIG_COMPACTION adds 0.1% to my kernel
On Wed, 11 Jul 2012, Minchan Kim wrote:
I agree it's an ideal but the problem is that it's too late.
Once product is released, we have to recall all products in the worst case.
The fact is that lumpy have helped high order allocation implicitly but we
removed it
without any notification or
On Wed, 11 Jul 2012, Arnd Bergmann wrote:
Also, size_t seems to be the correct type here, while the untyped
definition is just an int.
Ok, sounds good, thanks.
Acked-by: David Rientjes rient...@google.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Tue, 10 Jul 2012, a...@linux-foundation.org wrote:
The patch titled
Subject: kernel/sys.c: fix mishandling of out of memory in poweroff
has been added to the -mm tree. Its filename is
kernel-sysc-fix-mishandling-of-out-of-memory-in-poweroff.patch
Before you just go and hit
On Thu, 12 Jul 2012, Minchan Kim wrote:
There is QA team in embedded company and they have tested their product.
In test scenario, they can allocate 100 high order allocation.
(they don't matter how many high order allocations in kernel are needed
during test. their concern is just only
On Thu, 12 Jul 2012, Minchan Kim wrote:
Agreed and that's why I suggested following patch.
It's not elegant but at least, it could attract interest of configuration
people and they could find a regression during test phase.
This description could be improved later by writing new documenation
On Mon, 19 Nov 2012, Mel Gorman wrote:
I was not able to run a full sets of tests today as I was distracted so
all I have is a multi JVM comparison. I'll keep it shorter than average
3.7.0 3.7.0
rc5-stats-v4r2 rc5-schednuma-v16r1
On Mon, 19 Nov 2012, David Rientjes wrote:
I confirm that SPECjbb2005 1.07 -Xmx4g regresses in terms of throughput on
my 16-way, 4 node system with 32GB of memory using 16 warehouses and 240
measurement seconds. I averaged the throughput for five runs on each
kernel.
Java(TM) SE
for mem_cgroup_disabled() so we avoid the
unnecessary function call if memcg is disabled.
Signed-off-by: David Rientjes rient...@google.com
---
include/linux/memcontrol.h |9 -
mm/memcontrol.c|9 -
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/include/linux
On Tue, 20 Nov 2012, Ingo Molnar wrote:
numa/core at ec05a2311c35 (Merge branch 'sched/urgent' into
sched/core) had an average throughput of 136918.34
SPECjbb2005 bops, which is a 6.3% regression.
perftop during the run on numa/core at 01aa90068b12 (sched:
Use the best-buddy
On Tue, 20 Nov 2012, Ingo Molnar wrote:
No doubt numa/core should not regress with THP off or on and
I'll fix that.
As a background, here's how SPECjbb gets slower on mainline
(v3.7-rc6) if you boot Mel's kernel config and turn THP forcibly
off:
(avg: 502395 ops/sec)
(avg: 505902
On Tue, 20 Nov 2012, Ingo Molnar wrote:
I confirm that numa/core regresses significantly more without
thp than the 6.3% regression I reported with thp in terms of
throughput on the same system. numa/core at 01aa90068b12
(sched: Use the best-buddy 'ideal cpu' in balancing
decisions)
On Tue, 20 Nov 2012, Ingo Molnar wrote:
This happened to be an Opteron (but not 83xx series), 2.4Ghz.
Ok - roughly which family/model from /proc/cpuinfo?
It's close enough, it's 23xx.
It's perf top -U, the benchmark itself was unchanged so I
didn't think it was interesting to
On Mon, 19 Nov 2012, Glauber Costa wrote:
In the case I outlined below, for backwards compatibility. What I
actually mean is that memcg *currently* allows arbitrary notifications.
One way to merge those, while moving to a saner 3-point notification, is
to still allow the old writes and
On Mon, 19 Nov 2012, Anton Vorontsov wrote:
We try to make userland freeing resources when the system becomes low on
memory. Once we're short on memory, sometimes it's better to discard
(free) data, rather than let the kernel to drain file caches or even start
swapping.
To add another
On Mon, 19 Nov 2012, Glauber Costa wrote:
Because cpusets only deal with memory placement, not memory usage.
The set of nodes that a thread is allowed to allocate from may face memory
pressure up to and including oom while the rest of the system may have a
ton of free memory. Your
On Tue, 20 Nov 2012, Ingo Molnar wrote:
Subject: x86/vsyscall: Add Kconfig option to use native vsyscalls, switch to
it
From: Ingo Molnar mi...@kernel.org
Apparently there's still plenty of systems out there triggering
the vsyscall emulation page faults - causing hard to track down
On Tue, 20 Nov 2012, Ingo Molnar wrote:
Subject: x86/mm: Don't flush the TLB on #WP pmd fixups
From: Ingo Molnar mi...@kernel.org
Date: Tue Nov 20 14:46:34 CET 2012
If we have a write protection #PF and fix up the pmd then the
hugetlb code [the only user of pmdp_set_access_flags], in its
Cc: Andrew Morton a...@linux-foundation.org
Cc: Peter Zijlstra a.p.zijls...@chello.nl
Cc: Andrea Arcangeli aarca...@redhat.com
Cc: Rik van Riel r...@redhat.com
Cc: Hugh Dickins hu...@google.com
Signed-off-by: Ingo Molnar mi...@kernel.org
Acked-by: David Rientjes rient...@google.com
Ok
Move the check for !mm out of line as suggested by Andrew.
Signed-off-by: David Rientjes rient...@google.com
---
include/linux/memcontrol.h |2 +-
mm/memcontrol.c|3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/memcontrol.h b/include/linux
On Tue, 20 Nov 2012, Ingo Molnar wrote:
The current updated table of performance results is:
-
[ seconds ]v3.7 AutoNUMA | numa/core-v16[ vs. v3.7]
[ lower is better ] - |
On Wed, 21 Nov 2012, Ingo Molnar wrote:
Btw., what I did was to simply look at David's profile on the
regressing system and I compared it to the profile I got on a
pretty similar (but unfortunately not identical and not
regressing) system. I saw 3 differences:
- the numa emulation
On Tue, 27 Nov 2012, Bernd Schubert wrote:
I'm just investigating why a user space program has a rather large VmSize, but
small VmRSS size. Looking into /proc/$pid/smaps I notice several areas with an
size of about 64MB, but otherwise that area is unused. So far I did not find a
way how to
On Tue, 27 Nov 2012, Jiri Slaby wrote:
Hi,
I've hit BUG_ON(atomic_dec_and_test(huge_zero_refcount)) in
put_huge_zero_page right now. There are some Bad rss-counter state
before that, but those are perhaps unrelated as I saw many of them in
the previous -next. But even with yesterday's next
with attribute error: BUILD_BUG failed
The problem is that HPAGE_PMD_SHIFT triggers a BUILD_BUG() on
!CONFIG_TRANSPARENT_HUGEPAGE. This patch addresses the problem.
Reported-by: Michal Hocko mho...@suse.cz
Signed-off-by: Mel Gorman mgor...@suse.de
Acked-by: David Rientjes rient...@google.com
: error: implicit declaration of function 'set_pmd_at'
This is because paravirt defines set_pmd_at() only when
CONFIG_TRANSPARENT_HUGEPAGE=y and such a restriction is unneeded. The fix
is to define it for all CONFIG_PARAVIRT configurations.
Signed-off-by: David Rientjes rient...@google.com
On Mon, 17 Dec 2012, Andrew Morton wrote:
The kbuild test robot reported the following after the merge of Automatic
NUMA Balancing when cross-compiling for avr32.
mm/memory.c: In function 'do_pmd_numa_page':
mm/memory.c:3593: warning: no return statement in function returning
On Tue, 18 Dec 2012, Doug Anderson wrote:
The recent commit block: discard granularity might not be power of 2
introduced a divide by 0 in the kernel. Previously the code didn't
try to divide by discard_granularity when max_discard_sectors was 0.
Fix the code to only do the division if
On Mon, 17 Dec 2012, Sasha Levin wrote:
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 827d9c8..2a0ef01 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -20,6 +20,7 @@
#include linux/mman.h
#include linux/pagemap.h
+#include linux/hashtable.h
#include asm/tlb.h
501 - 600 of 6071 matches
Mail list logo
