On Wed, 14 Nov 2012, Andrew Morton wrote:
> For this reason and for general ease-of-testing: can and should we add
> a knob which will enable users to disable the feature at runtime? That
> way if it causes problems or if we suspect it's causing problems, we
> can easily verify the theory and off
On Thu, 15 Nov 2012, Glauber Costa wrote:
> Andrew,
>
> As you requested, here are some fixups and clarifications for the kmemcg
> series.
> It also handles one bug reported by Sasha.
>
On the series:
Acked-by: David Rientjes
--
To unsubscribe from this list: send the line
On Wed, 14 Nov 2012, Randy Dunlap wrote:
> --- linux-next-20121114.orig/include/asm-generic/bug.h
> +++ linux-next-20121114/include/asm-generic/bug.h
> @@ -129,6 +129,10 @@ extern void warn_slowpath_null(const cha
> })
> #endif
>
> +#ifndef __WARN
> +#define __WARN() do {} while (0)
> +#en
On Wed, 14 Nov 2012, Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix build when CONFIG_BUG is not enabled by adding header file
> :
>
> mm/balloon_compaction.c: In function 'balloon_page_putback':
> mm/balloon_compaction.c:243:3: error: implicit declaration of function
> '__WARN'
>
This is
On Wed, 7 Nov 2012, Kirill A. Shutemov wrote:
> > > Sorry, I didn't follow previous discussion on this, but could you
> > > explain what's wrong with memory notifications from memcg?
> > > As I can see you can get pretty similar functionality using memory
> > > thresholds on the root cgroup. What'
On Wed, 14 Nov 2012, Nithin Nayak Sujir wrote:
> This was fixed by
>
> commit de0a41484c47d783dd4d442914815076aa2caac2
> Author: Paul Gortmaker
> Date: Mon Oct 1 11:43:49 2012 -0400
>
> tg3: unconditionally select HWMON support when tg3 is enabled.
>
Would you mind submitting this for s
On Wed, 14 Nov 2012, Anton Vorontsov wrote:
> > I agree that eventfd is the way to go, but I'll also add that this feature
> > seems to be implemented at a far too coarse of level. Memory, and hence
> > memory pressure, is constrained by several factors other than just the
> > amount of physic
body can use it accidently again. It will be the only
subsystem allowed to use task handoffs.
Signed-off-by: David Rientjes
---
drivers/oprofile/buffer_sync.c | 18 ++
include/linux/profile.h| 35 +--
kernel/profile.c
Since the task handoff notifier is isolated only to oprofile, it no
longer consists of a possible chain of notifiers. Thus, it's easy to
replace it with a simple linked list when enabled, which is anytime that
the notifier would have been registered.
Signed-off-by: David Rientjes
---
dr
On Thu, 15 Nov 2012, Nithin Sujir wrote:
> > Would you mind submitting this for stable by following the procedure
> > described in Documentation/stable_kernel_rules.txt?
>
>
> Seems to have been taken into stable already.
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=com
On Wed, 14 Nov 2012, Anton Vorontsov wrote:
> Thanks again for your inspirational comments!
>
Heh, not sure I've been too inspirational (probably more annoying than
anything else). I really do want generic memory pressure notifications in
the kernel and already have some ideas on how I can ti
On Thu, 15 Nov 2012, Kirill A. Shutemov wrote:
> > > @@ -778,6 +790,11 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct
> > > mm_struct *src_mm,
> > > pte_free(dst_mm, pgtable);
> > > goto out_unlock;
> > > }
> > > + if (is_huge_zero_pmd(pmd)) {
> > > + set_huge
On Mon, 5 Nov 2012, Kees Cook wrote:
> diff --git a/mm/Kconfig b/mm/Kconfig
> index a3f8ddd..679945e 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -1,6 +1,5 @@
> config SELECT_MEMORY_MODEL
> def_bool y
> - depends on EXPERIMENTAL || ARCH_SELECT_MEMORY_MODEL
>
> choice
> pro
On Mon, 5 Nov 2012, Kees Cook wrote:
> >>> diff --git a/mm/Kconfig b/mm/Kconfig
> >>> index a3f8ddd..679945e 100644
> >>> --- a/mm/Kconfig
> >>> +++ b/mm/Kconfig
> >>> @@ -1,6 +1,5 @@
> >>> config SELECT_MEMORY_MODEL
> >>> def_bool y
> >>> - depends on EXPERIMENTAL || ARCH_SELECT_MEMORY
On Tue, 6 Nov 2012, Alan Cox wrote:
> From: Alan Cox
>
> The array check is useless so remove it.
>
> Signed-off-by: Alan Cox
Acked-by: David Rientjes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
ate':
drivers/acpi/device_pm.c:221: undefined reference to `acpi_target_system_state'
Define it only for CONFIG_ACPI_SLEEP and fallback to a dummy definition
for other configs.
Signed-off-by: David Rientjes
---
include/acpi/acpi_bus.h |8 ++--
1 files changed, 6 insertions(
Remove some duplicate code and simplify alloc_pages_vma(). No functional
change.
Signed-off-by: David Rientjes
---
mm/mempolicy.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
--- a/mm/mempolicy.c
+++ b/mm
On Wed, 7 Nov 2012, Sha Zhengju wrote:
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 0eab7d5..2df5e72 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -118,6 +118,14 @@ static const char * const mem_cgroup_events_names[] = {
> "pgmajfault",
> };
>
> +static const cha
rcu lock isn't actually that impressive here, the cgroup
iterator will use it's own lock for that memcg.
> Signed-off-by: Sha Zhengju
> Cc: Michal Hocko
> Cc: KAMEZAWA Hiroyuki
> Cc: David Rientjes
> Cc: Andrew Morton
> ---
> include/linux/memcontrol.h |
this member to specify that threads should be killed
first in oom conditions without playing around with oom_score_adj.
This also allows the correct oom_score_adj to always be shown when
reading /proc/pid/oom_score.
Signed-off-by: David Rientjes
---
include/linux/oom.h |
The maximum oom_score_adj is 1000 and the minimum oom_score_adj is -1000,
so this range can be represented by the signed short type with no
functional change. The extra space this frees up in struct signal_struct
will be used for per-thread oom kill flags in the next patch.
Signed-off-by: David
ate':
drivers/acpi/device_pm.c:221: undefined reference to `acpi_target_system_state'
Define it only for CONFIG_ACPI_SLEEP and fallback to a dummy definition
for other configs.
Signed-off-by: David Rientjes
---
include/acpi/acpi_bus.h |8 ++--
1 files changed, 6 insertions(
On Thu, 8 Nov 2012, KY Srinivasan wrote:
> > Thanks Michal. Yes, the kernel driver reports this metric to the host.
> > Andrew, let me know how I should proceed here.
>
> Ping.
>
Could you respond to my email in this thread?
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
On Thu, 8 Nov 2012, Andrew Morton wrote:
> > > I don't think you should export the symbol itself to modules but rather a
> > > helper function that returns s64 that just wraps
> > > percpu_counter_read_positive() which your driver could use instead.
> > >
> > > (And why percpu_counter_read_positi
ARN() directly.
Signed-off-by: David Rientjes
---
mm/balloon_compaction.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
index 32927eb..ddb0951 100644
--- a/mm/balloon_compaction.c
+++ b/mm/balloon_compact
On Fri, 9 Nov 2012, Randy Dunlap wrote:
> on i386:
>
> mm/balloon_compaction.c: In function 'balloon_page_putback':
> mm/balloon_compaction.c:243:3: error: implicit declaration of function
> '__WARN'
>
Sent a fix for this an hour ago:
http://marc.info/?l=linux-kernel&m=135249681031225
--
To u
On Fri, 9 Nov 2012, Randy Dunlap wrote:
> on x86_64:
>
> drivers/built-in.o: In function `acpi_pm_device_sleep_state':
> (.text+0x21855): undefined reference to `acpi_target_system_state'
> drivers/built-in.o: In function `acpi_pm_device_sleep_wake':
> (.text+0x2198e): undefined reference to `acp
On Sat, 10 Nov 2012, K. Y. Srinivasan wrote:
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 2d94235..e527239 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -89,6 +89,17 @@ int sysctl_max_map_count __read_mostly =
> DEFAULT_MAX_MAP_COUNT;
> struct percpu_counter vm_committed_as cacheline_align
On Thu, 20 Dec 2012, tip-bot for David Woodhouse wrote:
> diff --git a/Makefile b/Makefile
> index 540f7b2..9a07340 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -165,7 +165,8 @@ export srctree objtree VPATH
> # then ARCH is assigned, getting whatever value it gets normally, and
> # SUBARCH is
On Wed, 26 Dec 2012, David Woodhouse wrote:
> > arch/x86/built-in.o: In function `hpet_setup_msi_irq':
> > hpet.c:(.text+0x34638): undefined reference to `arch_setup_hpet_msi'
> > hpet.c:(.text+0x34651): undefined reference to `destroy_irq'
> > arch/x86/built-in.o: In function `hpet_msi_capability
On Wed, 26 Dec 2012, David Woodhouse wrote:
> Thanks. I'll look into this. I presume it was *always* failing, but
> nobody happened to come across it because our test coverage of x86
> configs without CONFIG_64BIT wasn't particularly good?
>
Purely for selfish reasons, 32-bit isn't interesting f
On Sat, 22 Dec 2012, Michal Nazarewicz wrote:
> So I think just adding the following, should be sufficient to make
> everyone happy:
>
> diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
> index e34e3e0..e91743b 100644
> --- a/drivers/base/dma-contiguous.c
> +++ b/drivers
On Sun, 23 Dec 2012, Sasha Levin wrote:
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 6b5fb76..72a0db6 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -401,7 +401,7 @@ void __init sparse_mem_maps_populate_node(struct page
> **map_map,
> }
>
> size = PAGE_ALIGN(size);
> -
On Sun, 23 Dec 2012, Sasha Levin wrote:
> diff --git a/mm/bootmem.c b/mm/bootmem.c
> index 1324cd7..198a92f 100644
> --- a/mm/bootmem.c
> +++ b/mm/bootmem.c
> @@ -763,9 +763,6 @@ void * __init ___alloc_bootmem_node(pg_data_t *pgdat,
> unsigned long size,
> void * __init __alloc_bootmem_node(pg_d
On Sun, 23 Dec 2012, Sasha Levin wrote:
> There's no need to check the result of alloc_bootmem() functions since
> they'll panic if allocation fails.
>
> Signed-off-by: Sasha Levin
Acked-by: David Rientjes
--
To unsubscribe from this list: send the line "unsubscrib
On Fri, 28 Dec 2012, Pekka Enberg wrote:
> On Sun, 23 Dec 2012, Sasha Levin wrote:
> >> diff --git a/mm/bootmem.c b/mm/bootmem.c
> >> index 1324cd7..198a92f 100644
> >> --- a/mm/bootmem.c
> >> +++ b/mm/bootmem.c
> >> @@ -763,9 +763,6 @@ void * __init ___alloc_bootmem_node(pg_data_t *pgdat,
> >> u
On Thu, 27 Dec 2012, Liu Hui-R64343 wrote:
> diff --git a/mm/compaction.c b/mm/compaction.c
> index c4bc5ac..d3cb27f 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -732,8 +732,10 @@ int sysctl_compact_memory;
> int sysctl_compaction_handler(struct ctl_table *table, int write,
>
On Thu, 27 Dec 2012, Sasha Levin wrote:
> That's exactly what happens with the patch. Note that in the current upstream
> version there are several slab checks scattered all over.
>
> In this case for example, I'm removing it from __alloc_bootmem_node(), but the
> first code line of__alloc_bootme
ledâ?? declared
> 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
> Signed-off-by: Mel Gorman
Acked-by: David Rientjes
Fixes the build issue for me, thanks.
tnuma':
mm/mprotect.c:120: 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: D
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
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
> #include
>
> +#include
> #include
> #include
> #include "internal.h"
Why group
On Wed, 19 Dec 2012, Sasha Levin wrote:
> In this case, the downside is that you'll waste 8KB if hugepages aren't
> available,
> but the upside is that you'll have one less dereference when accessing the
> hashtable.
>
> If the 8KB saving is preferable here I'll drop the patch and come back when
On Thu, 20 Dec 2012, Sasha Levin wrote:
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 6b5fb76..ae64d6e 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -403,15 +403,13 @@ void __init sparse_mem_maps_populate_node(struct page
> **map_map,
> size = PAGE_ALIGN(size);
> map = __allo
On Thu, 20 Dec 2012, Sasha Levin wrote:
> So what we really need is to update the documentation of
> __alloc_bootmem_node, I'll send
> a patch that does that instead.
>
It panics iff slab is not available to allocate from yet, otherwise it's
just a wrapper around kmalloc(). This emits a warni
On Thu, 20 Dec 2012, Linus Torvalds wrote:
> Going through some old emails before -rc1 rlease..
>
> What is the status of this patch? The patch that is reported to cause
> the problem hasn't been merged, but that mpol_misplaced() thing did
> happen in commit 771fb4d806a9. And it looks like it's c
On Thu, 20 Dec 2012, Andrew Morton wrote:
> > Specifying negative size of buffer makes no sense and thus this commit
> > changes the type of the count argument to unsigned.
> >
> > --- a/arch/arm/mm/dma-mapping.c
> > +++ b/arch/arm/mm/dma-mapping.c
> > @@ -1038,9 +1038,9 @@ static struct page **_
On Thu, 15 Nov 2012, Kamezawa Hiroyuki wrote:
> > @@ -708,15 +671,17 @@ out:
> >
> > /*
> >* The pagefault handler calls here because it is out of memory, so kill a
> > - * memory-hogging task. If a populated zone has ZONE_OOM_LOCKED set, a
> > parallel
> > - * oom killing is already in pr
On Thu, 15 Nov 2012, Anton Vorontsov wrote:
> Hehe, you're saying that we have to have cgroups=y. :) But some folks were
> deliberately asking us to make the cgroups optional.
>
Enabling just CONFIG_CGROUPS (which is enabled by default) and no other
current cgroups increases the size of the ker
highmem zones' present_pages becomes zero.
>
> Various options for improving the situation are being discussed but for
> now, let's return to the 3.6 code.
>
> Cc: Jianguo Wu
> Cc: Jiang Liu
> Cc: Petr Tesarik
> Cc: "Luck, Tony"
> Cc: Mel Gorman
&
On Thu, 15 Nov 2012, Jiang Liu wrote:
> I feel that zone->present_pages has been abused. I guess it means "physical
> pages
> present in this zone" originally, but now sometimes zone->present_pages is
> used as
> "pages in this zone managed by the buddy system".
It's definition is all pages sp
On Thu, 15 Nov 2012, Kirill A. Shutemov wrote:
> > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > > index d767a7c..05490b3 100644
> > > --- a/mm/huge_memory.c
> > > +++ b/mm/huge_memory.c
> > > @@ -1259,6 +1259,8 @@ int change_huge_pmd(struct vm_area_struct *vma,
> > > pmd_t *pmd,
> > >
On Thu, 15 Nov 2012, Kirill A. Shutemov wrote:
> > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > > index f36bc7d..41f05f1 100644
> > > --- a/mm/huge_memory.c
> > > +++ b/mm/huge_memory.c
> > > @@ -726,6 +726,16 @@ int do_huge_pmd_anonymous_page(struct mm_struct *mm,
> > > struct vm_area_
Fix comment
Signed-off-by: David Rientjes
---
mm/huge_memory.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -791,7 +791,7 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct
On Thu, 15 Nov 2012, Wen Congyang wrote:
> Note:
> 1. The following commit in pm tree can be dropped now(The other two patches
>are already dropped):
>54c4c7db6cb94d7d1217df6d7fca6847c61744ab
> 2. This patchset requires the following patch(It is in pm tree now)
>https://lkml.org/lkml/2
; acpi_memory_device_remove() and acpi_memory_disable_device().
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Motohiro
> CC: Rafael
memory_device_remove()
> which is protected by device_lock().
>
You mean it's protected by device_lock() before calling the remove()
function for eject?
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph
On Thu, 15 Nov 2012, Wen Congyang wrote:
> We allocate memory to store acpi_memory_info, so we should free it before
> freeing mem_device.
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph
eszutek Wilk
> Signed-off-by: Wen Congyang
Acked-by: David Rientjes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, 15 Nov 2012, Wen Congyang wrote:
> We eject the memory device even if it is in use. It is very dangerous,
> and it will cause the kernel to be panicked.
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
o allow that the device can be bound when the
> driver is being loaded.
>
> CC: David Rientjes
> CC: Jiang Liu
> CC: Len Brown
> CC: Benjamin Herrenschmidt
> CC: Paul Mackerras
> CC: Christoph Lameter
> Cc: Minchan Kim
> CC: Andrew Morton
> CC: KOSAKI Moto
On Thu, 15 Nov 2012, James Cloos wrote:
> The kernel does not log anything relevant to this.
>
Can you do the following as root:
dmesg -c > /dev/null
echo m > /proc/sysrq-trigger
dmesg > foo
and send foo inline in your reply?
> Slabinfo gives some odd output. It seems
o x86 maintainers]
Acked-by: David Rientjes
Do you want to fix arch/s390/include/asm/pgtable.h in the same way in a
separate patch and send it to Martin Schwidefsky
and Heiko Carstens ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
argument is of type 'pmd_t'
>
> Signed-off-by: Kirill A. Shutemov
[routing to Ingo for numa/core, which this is based on]
Acked-by: David Rientjes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Fri, 16 Nov 2012, Eilon Greenstein wrote:
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 21a9f5d..7a9c153 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3579,6 +3579,13 @@ sub process {
> WARN("EXPORTED_WORLD_WRITABLE",
>
On Fri, 16 Nov 2012, Glauber Costa wrote:
> My personal take:
>
> Most people hate memcg due to the cost it imposes. I've already
> demonstrated that with some effort, it doesn't necessarily have to be
> so. (http://lwn.net/Articles/517634/)
>
> The one thing I missed on that work, was precisely
On Fri, 16 Nov 2012, Kirill A. Shutemov wrote:
> > > > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > > > > index d767a7c..05490b3 100644
> > > > > --- a/mm/huge_memory.c
> > > > > +++ b/mm/huge_memory.c
> > > > > @@ -1259,6 +1259,8 @@ int change_huge_pmd(struct vm_area_struct *vma,
> > >
On Sat, 17 Nov 2012, Glauber Costa wrote:
> > I'm wondering if we should have more than three different levels.
> >
>
> 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 movi
On Wed, 14 Nov 2012, Nithin Nayak Sujir wrote:
> On 11/14/2012 07:30 PM, David Rientjes wrote:
> > On Wed, 14 Nov 2012, Nithin Nayak Sujir wrote:
> >
> > > This was fixed by
> > >
> > > commit de0a41484c47d783dd4d442914815076aa2caac2
> > > Au
On Fri, 16 Nov 2012, Anton Vorontsov wrote:
> The main change is that I decided to go with discrete levels of the
> pressure.
>
> When I started writing the man page, I had to describe the 'reclaimer
> inefficiency index', and while doing this I realized that I'm describing
> how the kernel
On Sat, 17 Nov 2012, Marc Duponcheel wrote:
> # echo always >/sys/kernel/mm/transparent_hugepage/enabled
> # while [ 1 ]
> do
>sleep 10
>date
>echo = vmstat
>egrep "(thp|compact)" /proc/vmstat
>echo = khugepaged stack
>cat /proc/501/stack
> done > /tmp/49361.
> # eme
gcc (-Wmissing-prototypes) and from
> Sparse (-Wdecl).
>
> mm/rmap.c:1440:6: warning: no previous prototype for ‘is_vma_temporary_stack’
> [-Wmissing-prototypes]
>
> Signed-off-by: Josh Triplett
Acked-by: David Rientjes
On Sun, 18 Nov 2012, Josh Triplett wrote:
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index 3f39803..8ed2187 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -55,6 +55,10 @@ extern pmd_t *page_check_address_pmd(struct page *page,
>
> extern bool
-Wmissing-prototypes]
>
> Signed-off-by: Josh Triplett
Acked-by: David Rientjes
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-v1
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.
>
mem_cgroup_disabled() so we avoid the
unnecessary function call if memcg is disabled.
Signed-off-by: David Rientjes
---
include/linux/memcontrol.h |9 -
mm/memcontrol.c|9 -
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/include/linux/memcontrol.h b
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
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
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
> >
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
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 wr
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 memor
On Tue, 16 Apr 2013, Oskar Andero wrote:
> > > The comment in shrinker.h is misleading, not the source code.
> > > do_shrinker_shrink() will fail for anything negative and 0.
> >
> > The comment is correct. The only acceptable negative return is -1.
> > Look at the second time do_shrinker_shrink
On Tue, 16 Apr 2013, Han Pingtian wrote:
> Hi list,
>
> On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
> something like "make -j 64" to compile linux kernel from source, sooner
> or latter, oom-killer will be triggered. Before that, when I trying to
> analyse the live sys
On Fri, 12 Apr 2013, Jiang Liu wrote:
> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
> index 901177d..305c68b 100644
> --- a/arch/x86/pci/common.c
> +++ b/arch/x86/pci/common.c
> @@ -6,6 +6,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1
On Wed, 17 Apr 2013, Yasuaki Ishimatsu wrote:
> When hot removing memory presented at boot time, following messages are shown:
>
> [ 296.867031] [ cut here ]
> [ 296.922273] kernel BUG at mm/slub.c:3409!
> [ 296.970229] invalid opcode: [#1] SMP
> [ 297.019453] Mod
ediately granted for processes with pending SIGKILLs and those in the
exit path, to be equivalent to what is done for the global oom killer.
Acked-by: Michal Hocko
Acked-by: KAMEZAWA Hiroyuki
Acked-by: Johannes Weiner
Signed-off-by: David Rientjes
---
mm/memcontrol.c | 8
1 file ch
On Wed, 17 Apr 2013, Yasuaki Ishimatsu wrote:
> > Why not simply do what generic sparsemem support does by testing
> > PageSlab(virt_to_head_page(res)) and calling kfree() if true and freeing
> > back to bootmem if false? This should be like a five line patch.
>
> Is your explanation about free_
On Wed, 17 Apr 2013, Yasuaki Ishimatsu wrote:
> > How much memory are we talking about?
>
> Hmm. I don't know correctly.
>
> Here is kernel message of my system. The message is shown by mem_init().
>
Do you have an estimate on the amount of struct resource memory that will
be leaked if entire
On Mon, 15 Apr 2013, Libin wrote:
> diff --git a/drivers/char/mspec.c b/drivers/char/mspec.c
> index e1f60f9..ed0703f 100644
> --- a/drivers/char/mspec.c
> +++ b/drivers/char/mspec.c
> @@ -168,7 +168,7 @@ mspec_close(struct vm_area_struct *vma)
> if (!atomic_dec_and_test(&vdata->refcnt))
>
On Tue, 16 Apr 2013, Bjorn Helgaas wrote:
> Thanks for the report!
>
> I'm pretty sure I fixed this:
> http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/jiang-subdrivers&id=3b63aaa70e1ccc4b66d60acc78da09700706a703
>
> The acpi_pci_add_bus()/acpi_pci_remove_bus() stubs for
n function `tps65912_device_init':
(.text+0x5884c): undefined reference to `mfd_remove_devices'
drivers/built-in.o: In function `tps65912_device_exit':
(.text+0x58878): undefined reference to `mfd_remove_devices'
Signed-off-by: David Rientjes
---
drivers/mfd/Kc
On Wed, 17 Apr 2013, Randy Dunlap wrote:
> On 04/17/13 00:04, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20130416:
> >
>
>
> on i386, SMP is disabled, X86_UP_APIC is not enabled, but
> CONFIG_KVM_APIC_ARCHITECTURE=y:
>
> arch/x86/kvm/vmx.c: In function 'vmx_deliver_posted_inter
unlap
Signed-off-by: David Rientjes
---
arch/x86/kvm/vmx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -34,6 +34,7 @@
#include "kvm_cache_regs.h"
#include "x86.h"
+#include
out why the builtin_constant_p() was used.
>
> This patch is just a clean up that makes the index_of() code a little
> bit less complex.
>
> Signed-off-by: Steven Rostedt
Acked-by: David Rientjes
Adding Pekka to the cc.
>
> diff --git a/mm/slab.c b/mm/slab.c
> index
On Wed, 17 Apr 2013, Randy Dunlap wrote:
> On 04/17/13 16:12, David Rientjes wrote:
> > The build fails when CONFIG_SMP is disabled:
> >
> > arch/x86/kvm/vmx.c: In function 'vmx_deliver_posted_interrupt':
> > arch/x86/kvm/vmx.c:3950:3: error:
On Thu, 18 Apr 2013, Will Huck wrote:
> In normal case, builtin_constant_p() is used for what?
>
http://gcc.gnu.org/onlinedocs/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ker
301 - 400 of 3171 matches
Mail list logo
