On Mon, Nov 26, 2012 at 02:18:37PM +0100, Michal Hocko wrote:
> [CCing also Johannes - the thread started here:
> https://lkml.org/lkml/2012/11/21/497]
>
> On Mon 26-11-12 01:38:55, azurIt wrote:
> > >This is hackish but it should help you in this case. Kamezawa, what do
> > >you think about that?
On Mon, Nov 26, 2012 at 07:04:44PM +0100, Michal Hocko wrote:
> On Mon 26-11-12 12:46:22, Johannes Weiner wrote:
> > On Mon, Nov 26, 2012 at 02:18:37PM +0100, Michal Hocko wrote:
> > > [CCing also Johannes - the thread started here:
> > > https://lkml.org/lkml/2012/11/
like to use "bool" for such flags where possible;
> it helps document the intent of the variable better.
Any chance you could test with this fix instead, in addition to Dave's
accounting fix? It's got bool and everything!
---
From: Johannes Weiner
Subject: [patch] mm: vmsc
On Mon, Nov 26, 2012 at 08:03:29PM +0100, Michal Hocko wrote:
> On Mon 26-11-12 13:24:21, Johannes Weiner wrote:
> > On Mon, Nov 26, 2012 at 07:04:44PM +0100, Michal Hocko wrote:
> > > On Mon 26-11-12 12:46:22, Johannes Weiner wrote:
> [...]
> > > > I think glo
On Mon, Nov 26, 2012 at 09:08:48PM +0100, Michal Hocko wrote:
> On Mon 26-11-12 14:29:41, Johannes Weiner wrote:
> > On Mon, Nov 26, 2012 at 08:03:29PM +0100, Michal Hocko wrote:
> > > On Mon 26-11-12 13:24:21, Johannes Weiner wrote:
> > > > On Mon, Nov 26, 2012 at
On Mon, Nov 26, 2012 at 09:46:38PM +0100, azurIt wrote:
> >This issue has been around for a while so frankly I don't think it's
> >urgent enough to rush things.
>
>
> Well, it's quite urgent at least for us :( i wasn't reported this so
> far cos i wasn't sure it's a kernel thing. I will be really
70] FS: 7f0462b49700() GS:8804570c()
> knlGS:0
> 000
> [ 517.740170] CS: 0010 DS: ES: CR0: 8005003b
> [ 517.740170] CR2: 7f006dc5fd14 CR3: 000440e85000 CR4:
> 07e0
>
> [ 517.740170] DR0: 0000 DR1:
On Tue, Nov 27, 2012 at 09:05:30AM +0900, Kamezawa Hiroyuki wrote:
> (2012/11/26 22:18), Michal Hocko wrote:
> >[CCing also Johannes - the thread started here:
> >https://lkml.org/lkml/2012/11/21/497]
> >
> >On Mon 26-11-12 01:38:55, azurIt wrote:
> >>>This is hackish but it should help you in this
Hi everyone,
I hope I included everybody that participated in the various threads
on kswapd getting stuck / exhibiting high CPU usage. We were looking
at at least three root causes as far as I can see, so it's not really
clear who observed which problem. Please correct me if the
reported-by, tes
-off-by: Johannes Weiner
Tested-by: Johannes Hirte
Reviewed-by: Rik van Riel
---
mm/vmscan.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 48550c6..3b0aef4 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2397,6
On Tue, Nov 27, 2012 at 12:58:18PM -0800, Linus Torvalds wrote:
> Note that in the meantime, I've also applied (through Andrew) the
> patch that reverts commit c654345924f7 (see commit 82b212f40059
> 'Revert "mm: remove __GFP_NO_KSWAPD"').
>
> I wonder if that revert may be bogus, and a result of
On Tue, Nov 27, 2012 at 04:16:52PM -0500, Rik van Riel wrote:
> On 11/27/2012 03:58 PM, Linus Torvalds wrote:
> >Note that in the meantime, I've also applied (through Andrew) the
> >patch that reverts commit c654345924f7 (see commit 82b212f40059
> >'Revert "mm: remove __GFP_NO_KSWAPD"').
> >
> >I w
On Tue, Nov 27, 2012 at 05:02:36PM -0500, Rik van Riel wrote:
> On 11/27/2012 04:49 PM, Johannes Weiner wrote:
> >On Tue, Nov 27, 2012 at 04:16:52PM -0500, Rik van Riel wrote:
> >>On 11/27/2012 03:58 PM, Linus Torvalds wrote:
> >>>Note that in the meantime, I'v
On Tue, Nov 27, 2012 at 09:59:44PM +0100, Michal Hocko wrote:
> @@ -3863,7 +3862,7 @@ int mem_cgroup_cache_charge(struct page *page, struct
> mm_struct *mm,
> return 0;
>
> if (!PageSwapCache(page))
> - ret = mem_cgroup_charge_common(page, mm, gfp_mask, type);
> +
On Wed, Nov 28, 2012 at 05:04:47PM +0100, Michal Hocko wrote:
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 095d2b4..5abe441 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -57,13 +57,14 @@ extern int mem_cgroup_newpage_charge(struc
On Wed, Nov 28, 2012 at 05:48:24PM +0100, Michal Hocko wrote:
> On Wed 28-11-12 17:46:40, Michal Hocko wrote:
> > On Wed 28-11-12 11:37:36, Johannes Weiner wrote:
> > > On Wed, Nov 28, 2012 at 05:04:47PM +0100, Michal Hocko wrote:
> > > > diff --git a/include/linu
On Thu, Nov 29, 2012 at 04:30:12PM +0100, Thorsten Leemhuis wrote:
> Mel Gorman wrote on 29.11.2012 00:54:
> > On Wed, Nov 28, 2012 at 02:52:15PM -0800, Andrew Morton wrote:
> >> On Wed, 28 Nov 2012 10:13:59 +
> >> Mel Gorman wrote:
> >>
> >> > Based on the reports I've seen I expect the foll
On Thu, Nov 29, 2012 at 09:54:14AM -0500, George Spelvin wrote:
> Mel Gorman wrote:
> > On Tue, Nov 27, 2012 at 04:25:14PM -0500, George Spelvin wrote:
> >> Well, it just made it to 24 hours,
> >> it did before. I'm going to wait a couple more days before declaring
> >> victory, but it looks goo
d-and-tested-by: Bernhard Schmidt
Reference: http://bugs.debian.org/699913
Signed-off-by: Ben Hutchings
Signed-off-by: Johannes Weiner
---
mm/sparse-vmemmap.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 1b7e22a..22b7e18 1
ize and so this
unit is too coarse.
Just translate the section range into bytes once in the generic sparse
code, then pass byte ranges down the stack.
Signed-off-by: Johannes Weiner
---
arch/arm64/mm/mmu.c | 13 +
arch/ia64/mm/discontig.c | 7 +++
arch/power
Memory hotplug can happen on a machine under load, memory shortness
and fragmentation, so huge page allocations for the vmemmap are not
guaranteed to succeed.
Try to fall back to regular pages before failing the hotplug event
completely.
Signed-off-by: Johannes Weiner
---
arch/x86/mm/init_64.c
No need to maintain addr_end and p_end when they are never actually
read anywhere on !pse setups. Remove the dead code.
Signed-off-by: Johannes Weiner
---
arch/x86/mm/init_64.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 7dd132c
We already have generic code to allocate vmemmap with regular pages,
use it.
Signed-off-by: Johannes Weiner
---
arch/x86/mm/init_64.c | 81 ---
1 file changed, 38 insertions(+), 43 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm
Hotplug can happen at times when the memory situation is less than
perfect to allocate huge pages for the vmemmap. This series makes the
allocation try harder in patch #1. The remaining patches allow x86-64
to fall back to regular pages as a last resort before the hotplug
event fails completely.
-by: Mel Gorman
Nice, thank you. Using the high watermark for larger zones is more
reasonable than my hack that just always went with SWAP_CLUSTER_MAX,
what with inter-zone LRU cycle time balancing and all.
Acked-by: Johannes Weiner
--
To unsubscribe from this list: send the line "unsubscribe
On Sun, Mar 17, 2013 at 01:04:08PM +, Mel Gorman wrote:
> Simplistically, the anon and file LRU lists are scanned proportionally
> depending on the value of vm.swappiness although there are other factors
> taken into account by get_scan_count(). The patch "mm: vmscan: Limit
> the number of pag
ot then we are
> screwed anyway (this saves some code).
>
> Signed-off-by: Michal Hocko
Acked-by: Johannes Weiner
--
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
_cgroup_init along with other controller specific parts.
>
> This patch wrappes the current memcg_stock initialization code into a
> helper calls it from the controller subsystem initialization code.
>
> Signed-off-by: Michal Hocko
Acked-by: Johannes Weiner
--
To unsubscribe fr
; Signed-off-by: Michal Hocko
It seems a little strange to document that the subsystem init function
should be used for initializing the subsystem. But your new comment
is better than the old comment :-)
Acked-by: Johannes Weiner
--
To unsubscribe from this list: send the line "unsubscribe
On Sat, Feb 02, 2013 at 12:25:44PM +0400, Konstantin Khlebnikov wrote:
> Johannes Weiner wrote:
> >In shmem_find_get_pages_and_swap, use the faster radix tree iterator
> >construct from 78c1d78 "radix-tree: introduce bit-optimized iterator".
> >
> >Signed-
On Wed, Feb 06, 2013 at 01:09:55AM +0800, Zhang Yanfei wrote:
> Function nr_free_zone_pages, nr_free_buffer_pages and nr_free_pagecache_pages
> are horribly badly named, they count present_pages - pages_high within zones
> instead of free pages, so why not rename them to reasonable names, not
> co
Hi Chanho,
On Thu, Feb 07, 2013 at 11:27:54AM +0900, Chanho Min wrote:
> There is no reason to maintain alloc_map in the vmap_block.
> The use of alloc_map may require heavy bitmap operation sometimes.
> In the worst-case, We need 1024 for-loops to find 1 free bit and
> thus cause overhead. vmap_b
On Fri, Feb 08, 2013 at 12:37:13PM +0900, Chanho Min wrote:
> >I started looking for workloads to profile but then lost interest.
> >The current code can theoretically end up walking through a lot of
> >partially used blocks if a string of allocations never fit any of
> >them. The number of these
On Thu, Jan 03, 2013 at 06:54:18PM +0100, Michal Hocko wrote:
> Now that per-node-zone-priority iterator caches memory cgroups rather
> than their css ids we have to be careful and remove them from the
> iterator when they are on the way out otherwise they might hang for
> unbounded amount of time
On Mon, Feb 11, 2013 at 01:43:03PM +1030, Rusty Russell wrote:
> I am writing an app which really wants to know if a file is on the
> disk or not (ie. do I need to sync?).
When the page is under writeback, it's not necessarily on disk yet,
but you also don't need to sync. Which semantics make mor
On Mon, Feb 11, 2013 at 04:16:49PM +0100, Michal Hocko wrote:
> On Fri 08-02-13 14:33:18, Johannes Weiner wrote:
> [...]
> > for each in hierarchy:
> > for each node:
> > for each zone:
> > for each reclaim priority:
> >
> > every time a
On Mon, Feb 11, 2013 at 08:29:29PM +0100, Michal Hocko wrote:
> On Mon 11-02-13 12:56:19, Johannes Weiner wrote:
> > On Mon, Feb 11, 2013 at 04:16:49PM +0100, Michal Hocko wrote:
> > > Maybe we could keep the counter per memcg but that would mean that we
> > > would nee
On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
> On Mon 11-02-13 14:58:24, Johannes Weiner wrote:
> > On Mon, Feb 11, 2013 at 08:29:29PM +0100, Michal Hocko wrote:
> > > On Mon 11-02-13 12:56:19, Johannes Weiner wrote:
> > > > On Mon, Feb 11, 2013 at
ssing /proc/kcore so the patch has
> not been validated but I think it makes sense. If reviewers agree then it
> should also be included in -stable back as far as 3.0-stable.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Mel Gorman
Acked-by: Johannes Weiner
Agreed also on the bac
On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
> On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
> > On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
> > > On Mon 11-02-13 14:58:24, Johannes Weiner wrote:
> > > > That way, if the dead coun
Michal Hocko wrote:
>On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
>> On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
>> > On Mon 11-02-13 17:39:43, Johannes Weiner wrote:
>> > > On Mon, Feb 11, 2013 at 10:27:56PM +0100, Michal Hocko wrote:
>
Michal Hocko wrote:
>On Tue 12-02-13 17:13:32, Michal Hocko wrote:
>> On Tue 12-02-13 16:43:30, Michal Hocko wrote:
>> [...]
>> The example was not complete:
>>
>> > Wait a moment. But what prevents from the following race?
>> >
>> > rcu_read_lock()
>>
>> cgroup_next_descendant_pre
>> css_tr
On Tue, Feb 12, 2013 at 08:10:51AM -0800, Paul E. McKenney wrote:
> On Tue, Feb 12, 2013 at 04:43:30PM +0100, Michal Hocko wrote:
> > On Tue 12-02-13 10:10:02, Johannes Weiner wrote:
> > > On Tue, Feb 12, 2013 at 10:54:19AM +0100, Michal Hocko wrote:
> > > > On M
On Tue, Feb 12, 2013 at 06:12:16PM +0100, Michal Hocko wrote:
> On Tue 12-02-13 11:41:03, Johannes Weiner wrote:
> >
> >
> > Michal Hocko wrote:
> >
> > >On Tue 12-02-13 17:13:32, Michal Hocko wrote:
> > >> On Tue 12-02-13 16:43:30, Michal Hock
On Tue, Feb 12, 2013 at 10:31:48AM -0800, Paul E. McKenney wrote:
> On Tue, Feb 12, 2013 at 12:25:26PM -0500, Johannes Weiner wrote:
> > On Tue, Feb 12, 2013 at 08:10:51AM -0800, Paul E. McKenney wrote:
> > > On Tue, Feb 12, 2013 at 04:43:30PM +0100, Michal Hocko wrote:
> >
iteration. This allows
> __mem_cgroup_try_charge() to succeed so that the process may exit. This
> makes the memcg oom killer exemption for TIF_MEMDIE tasks, now
> immediately granted for processes with pending SIGKILLs and those in the
> exit path, to be equivalent to what is done for
On Tue, Jan 29, 2013 at 09:51:04AM +0100, Michal Hocko wrote:
> Ying has noticed me (via private email) that the patch is bogus because
> the break out condition is incorrect. She said she would post a fix
> but she's been probably too busy. If she doesn't oppose, could you add
> the follow up fix,
Inodes are added to the head of the superblock LRU list and reclaimed
from the tail. If trylocking an inode during reclaim fails, it has to
be moved to the head of the list, not the tail, to prevent spinning on
it.
Signed-off-by: Johannes Weiner
---
fs/inode.c | 4 ++--
1 file changed, 2
: the stack expansion mlocks only the newly
expanded range and so will not result in recursive expansion.
Reported-by: Al Viro
Signed-off-by: Johannes Weiner
---
mm/mlock.c | 4
1 file changed, 4 insertions(+)
diff --git a/mm/mlock.c b/mm/mlock.c
index b1647fb..78c4924 100644
--- a/mm
situations.
Get rid of inactive_file_is_low_global() and
mem_cgroup_inactive_file_is_low() by using get_lru_size() and compare
the numbers in common code.
Signed-off-by: Johannes Weiner
---
include/linux/memcontrol.h | 7 ---
mm/memcontrol.c| 11 ---
mm/vmscan.c
In shmem_find_get_pages_and_swap, use the faster radix tree iterator
construct from 78c1d78 "radix-tree: introduce bit-optimized iterator".
Signed-off-by: Johannes Weiner
---
mm/shmem.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/mm
On Tue, Feb 26, 2013 at 10:47:31AM +, Mel Gorman wrote:
> On Fri, Feb 22, 2013 at 12:56:34PM -0500, Johannes Weiner wrote:
> > > >
> > > >
> > > > : We have a server workload wherein machines with 100G+ of "free" memory
> > > > :
o_swap_page(), but have a strong
> aversion to how "swapcache" ends up being used there: rework it with
> "page != swapcache".
>
> Signed-off-by: Hugh Dickins
Acked-by: Johannes Weiner
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
On Tue, Feb 19, 2013 at 09:19:27PM -0800, dormando wrote:
> >
> > The problem is that adding this tunable will constrain future VM
> > implementations. We will forever need to at least retain the
> > pseudo-file. We will also need to make some effort to retain its
> > behaviour.
> >
> > It would
Hi,
On Thu, Sep 13, 2012 at 03:14:28PM +0800, Wen Congyang wrote:
> root_mem_cgroup->info.nodeinfo is initialized when the system boots.
> But NODE_DATA(nid) is null if the node is not onlined, so
> root_mem_cgroup->info.nodeinfo[nid]->zoneinfo[zone].lruvec.zone contains
> an invalid pointer. If w
On Thu, Sep 13, 2012 at 04:21:04PM -0400, Rik van Riel wrote:
> Now that lumpy reclaim has been removed, compaction is the
> only way left to free up contiguous memory areas. It is time
> to just enable CONFIG_COMPACTION by default.
>
> Signed-off-by: Rik van Riel
Acked-by:
On Thu, Sep 13, 2012 at 06:36:34PM -0700, Hugh Dickins wrote:
> On Thu, 13 Sep 2012, Johannes Weiner wrote:
> > On Thu, Sep 13, 2012 at 03:14:28PM +0800, Wen Congyang wrote:
> > > root_mem_cgroup->info.nodeinfo is initialized when the system boots.
> > > But NODE_DA
Hi,
Andrew Morton <[EMAIL PROTECTED]> writes:
> Question is: why do people keep adding new ones when they are so easy to
> detect and fix?
>
> Asnwer: because neither they nor their patch integrators are doing adequate
> compilation testing.
How about adding an Untested-by tag for psychological
t the
section of the surrounding function and then moves the data
automatically when it is a literal, but I couldn't find mechanisms that
allow this. Anyone of you got an idea?
What do you think in general?
Hannes
---
From: Johannes Weiner <[EMAIL PROTECTED]>
Sectionized printk wrap
Hi Sam,
Sam Ravnborg <[EMAIL PROTECTED]> writes:
> On Mon, Feb 04, 2008 at 04:48:34PM +0100, Johannes Weiner wrote:
>> Hi,
>>
>> current approaches to have printk format strings in the corresponding
>> data section to the function they appear in look like the f
Hi Andrew,
an older version of "mm: memcg: count pte references from every member
of the reclaimed hierarchy" patch made it into the 3.5
(c3ac9a8ade65ccbfd145fbff895ae8d8d62d09b0) by accident and I didn't
notice until just now. #1 is a fixup on top, tagged for 3.5-stable.
#2 is a cleanup you req
It really should return a boolean for match/no match. And since it
takes a memcg, not a cgroup, fix that parameter name as well.
Signed-off-by: Johannes Weiner
Acked-by: Michal Hocko
---
include/linux/memcontrol.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff
page_referenced() counts only references of mm's that are associated
with the memcg hierarchy that is being reclaimed. However, if it
races with the owner of the mm exiting, mm->owner may be NULL. Don't
crash, just ignore the reference.
Signed-off-by: Johannes Weiner
Cc: sta...@ke
On Thu, Oct 04, 2012 at 08:49:58PM +0200, Michal Hocko wrote:
> On Thu 04-10-12 14:09:16, Johannes Weiner wrote:
> > page_referenced() counts only references of mm's that are associated
> > with the memcg hierarchy that is being reclaimed. However, if it
> > races with t
On Thu, Oct 04, 2012 at 02:53:13PM +0400, Glauber Costa wrote:
> On 10/01/2012 05:27 PM, Michal Hocko wrote:
> > On Tue 18-09-12 18:04:09, Glauber Costa wrote:
> >> A lot of the initialization we do in mem_cgroup_create() is done with
> >> softirqs
> >> enabled. This include grabbing a css id, whi
aults on transparent hugepages which do not result
> in a CoW update the access flags for the faulting pmd.
>
> Cc: Chris Metcalf
> Cc: Kirill A. Shutemov
> Cc: Andrea Arcangeli
> Signed-off-by: Will Deacon
Acked-by: Johannes Weiner
> Ok chaps, I rebased this thing
On Wed, Oct 24, 2012 at 09:36:27PM -0700, Hugh Dickins wrote:
> On Wed, 24 Oct 2012, Dave Jones wrote:
>
> > Machine under significant load (4gb memory used, swap usage fluctuating)
> > triggered this...
> >
> > WARNING: at mm/shmem.c:1151 shmem_getpage_gfp+0xa5c/0xa70()
> > Pid: 29795, comm: tri
On Tue, Oct 30, 2012 at 02:42:04PM -0400, Rik van Riel wrote:
> If we have more inactive file pages than active file pages, we
> skip scanning the active file pages alltogether, with the idea
> that we do not want to evict the working set when there is
> plenty of streaming IO in the cache.
>
> Ho
responsibility for css reference counting to their callers
> to make to code easier.
>
> This patch doesn't have any functional changes.
>
> Signed-off-by: Michal Hocko
> Reviewed-by: Tejun Heo
Acked-by: Johannes Weiner
--
To unsubscribe from this list: send the line
m_cgroup_move_parent doesn't have to bother with the
> root cgroup and it can assume it can always move charges upwards.
>
> Signed-off-by: Michal Hocko
> Reviewed-by: Tejun Heo
Acked-by: Johannes Weiner
--
To unsubscribe from this list: send the line "unsubscribe linux-
On Mon, Jul 30, 2012 at 12:28:35AM +0200, Sasha Levin wrote:
> Hi all,
>
> I was poking around /dev/kmem related code, and noticed the following in
> mmap_kmem():
>
> /* Turn a kernel-virtual address into a physical page frame */
> pfn = __pa((u64)vma->vm_pgoff << PAGE_SHIFT) >>
On Fri, Sep 21, 2012 at 08:24:08AM +0900, Minchan Kim wrote:
> On Thu, Sep 20, 2012 at 11:41:11AM -0400, Johannes Weiner wrote:
> > On Thu, Sep 20, 2012 at 08:51:56AM +0900, Minchan Kim wrote:
> > > From: Minchan Kim
> > > Date: Thu, 20 Sep 2012 08:39:52 +0900
> &
ly enough if that turns out to be wrong.
>
> Signed-off-by: Hugh Dickins
> Cc: Mel Gorman
> Cc: Rik van Riel
> Cc: Johannes Weiner
> Cc: Michel Lespinasse
> Cc: Ying Han
Acked-by: Johannes Weiner
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
o_page_fault+0xe/0x10
> > [ 183.293705] [] page_fault+0x28/0x30
>
> Johannes, this looks like the thp migration memcg hookery gone bad,
> could you have a look at this?
Oops. Here is an incremental fix, feel free to fold it into #31.
Signed-off-by: Johannes Weiner
---
dif
elow is the folded up patch.
>
> Ingo
>
> >
> Subject: sched, numa, mm: Add memcg support to do_huge_pmd_numa_page()
> From: Johannes Weiner
> Date: Thu Oct 25 12:49:51 CEST 2012
>
> Add memory control group support to hugepage migration.
&g
On Tue, Oct 30, 2012 at 02:29:25PM +0800, Zhouping Liu wrote:
> On 10/29/2012 01:56 AM, Johannes Weiner wrote:
> >On Fri, Oct 26, 2012 at 11:08:00AM +0200, Peter Zijlstra wrote:
> >>On Fri, 2012-10-26 at 17:07 +0800, Zhouping Liu wrote:
> >&g
On Tue, Oct 01, 2013 at 04:31:23PM -0700, David Rientjes wrote:
> for_each_online_cpu() needs the protection of {get,put}_online_cpus() so
> cpu_online_mask doesn't change during the iteration.
There is no problem report here.
Is there a crash?
If it's just accuracy of the read, why would we car
> To: Ingo Molnar
> Cc: Linux Kernel
> Cc: Linux MM
> Cc: Rob Landley
> Cc: Mike Travis
> Cc: Daniel J Blueman
> Cc: Andrew Morton
> Cc: Greg KH
> Cc: Yinghai Lu
> Cc: Mel Gorman
Acked-by: Johannes Weiner
--
To unsubscribe from this list: send the line
Hi Greg,
On Wed, Sep 04, 2013 at 11:28:58PM -0700, Greg Thelen wrote:
> + struct numa_stat {
> + const char *name;
> + unsigned int lru_mask;
> + };
> +
> + static const struct numa_stat stats[] = {
> + { "total", LRU_ALL },
> + { "file",
Hello Greg!
On Wed, Sep 04, 2013 at 11:28:59PM -0700, Greg Thelen wrote:
> --- a/Documentation/cgroups/memory.txt
> +++ b/Documentation/cgroups/memory.txt
> @@ -571,15 +571,19 @@ an memcg since the pages are allowed to be allocated
> from any physical
> node. One of the use cases is evaluating
On Mon, Sep 16, 2013 at 05:05:43PM +0200, azurIt wrote:
> > CC: "Johannes Weiner" , "Andrew Morton"
> > , "David Rientjes" ,
> > "KAMEZAWA Hiroyuki" , "KOSAKI Motohiro"
> > , linux...@kvack.org,
> > cgro...
On Mon, Sep 16, 2013 at 10:52:46PM +0200, azurIt wrote:
> > CC: "Johannes Weiner" , "Andrew Morton"
> > , "David Rientjes" ,
> > "KAMEZAWA Hiroyuki" , "KOSAKI Motohiro"
> > , linux...@kvack.org,
> > cgro...
On Mon, Aug 05, 2013 at 09:20:13AM +0200, Michal Hocko wrote:
> On Sun 04-08-13 21:13:44, KOSAKI Motohiro wrote:
> > On Sun, Aug 4, 2013 at 4:07 AM, Michal Hocko wrote:
> > > On Sat 03-08-13 16:16:58, KOSAKI Motohiro wrote:
> > >> >>> You missed the "!". I'm proposing that setting the new bit 2 w
On Mon, Sep 16, 2013 at 06:44:05PM +0200, Michal Hocko wrote:
> On Fri 13-09-13 12:17:09, Johannes Weiner wrote:
> > On Fri, Sep 13, 2013 at 04:49:53PM +0200, Michal Hocko wrote:
> > > On Fri 06-09-13 15:23:11, Johannes Weiner wrote:
> [...]
> > > > I would really
On Wed, Sep 18, 2013 at 04:03:04PM +0200, azurIt wrote:
> > CC: "Johannes Weiner" , "Andrew Morton"
> > , "David Rientjes" ,
> > "KAMEZAWA Hiroyuki" , "KOSAKI Motohiro"
> > , linux...@kvack.org,
> > cgro...
On Wed, Sep 18, 2013 at 02:04:55PM -0400, Johannes Weiner wrote:
> On Wed, Sep 18, 2013 at 04:03:04PM +0200, azurIt wrote:
> > > CC: "Johannes Weiner" , "Andrew Morton"
> > > , "David Rientjes" ,
> > > "KAMEZAWA Hiroy
On Wed, Sep 18, 2013 at 02:19:46PM -0400, Johannes Weiner wrote:
> On Wed, Sep 18, 2013 at 02:04:55PM -0400, Johannes Weiner wrote:
> > On Wed, Sep 18, 2013 at 04:03:04PM +0200, azurIt wrote:
> > > > CC: "Johannes Weiner" , "Andrew Morton"
> > >
the log excert above suggests this fix is required either way.
---
From: Johannes Weiner
Subject: [patch] mm: memcg: handle non-error OOM situations more gracefully
Many places that can trigger a memcg OOM situation return gracefully
and don't propagate VM_FAULT_OOM up the fault sta
On Thu, Sep 05, 2013 at 02:43:52PM +0200, Michal Hocko wrote:
> On Thu 05-09-13 07:54:30, Johannes Weiner wrote:
> > There are a few more find_or_create() sites that do not propagate an
> > error and it's incredibly hard to find out whether they are even taken
> > duri
On Wed, Sep 04, 2013 at 06:38:23PM +0200, Michal Hocko wrote:
> On Tue 03-09-13 12:15:50, Johannes Weiner wrote:
> > > On Tue 20-08-13 10:13:39, Johannes Weiner wrote:
> > > > On Tue, Aug 20, 2013 at 11:14:14AM +0200, Michal Hocko wrote:
> > > > > On Mon 1
On Mon, Sep 09, 2013 at 03:10:10PM +0200, azurIt wrote:
> >Hi azur,
> >
> >On Wed, Sep 04, 2013 at 10:18:52AM +0200, azurIt wrote:
> >> > CC: "Andrew Morton" , "Michal Hocko"
> >> > , "David Rientjes" , "KAMEZAWA
> >> > Hiroyuki" , "KOSAKI Motohiro"
> >> > , linux...@kvack.org,
> >> > cgro...@v
On Mon, Sep 09, 2013 at 09:59:17PM +0200, azurIt wrote:
> >On Mon, Sep 09, 2013 at 03:10:10PM +0200, azurIt wrote:
> >> >Hi azur,
> >> >
> >> >On Wed, Sep 04, 2013 at 10:18:52AM +0200, azurIt wrote:
> >> >> > CC: "Andrew Morton" , "Michal Hocko"
> >> >> > , "David Rientjes" , "KAMEZAWA
> >> >> >
On Tue, Sep 10, 2013 at 08:13:59PM +0200, azurIt wrote:
> >On Mon, Sep 09, 2013 at 09:59:17PM +0200, azurIt wrote:
> >> >On Mon, Sep 09, 2013 at 03:10:10PM +0200, azurIt wrote:
> >> >> >Hi azur,
> >> >> >
> >> >> >On Wed, Sep 04, 2013 at 10:18:52AM +0200, azurIt wrote:
> >> >> >> > CC: "Andrew Mort
On Tue, Sep 10, 2013 at 09:32:53PM +0200, azurIt wrote:
> >On Tue, Sep 10, 2013 at 08:13:59PM +0200, azurIt wrote:
> >> >On Mon, Sep 09, 2013 at 09:59:17PM +0200, azurIt wrote:
> >> >> >On Mon, Sep 09, 2013 at 03:10:10PM +0200, azurIt wrote:
> >> >> >> >Hi azur,
> >> >> >> >
> >> >> >> >On Wed, Sep
On Tue, Sep 10, 2013 at 11:08:53PM +0200, azurIt wrote:
> >On Tue, Sep 10, 2013 at 09:32:53PM +0200, azurIt wrote:
> >> >On Tue, Sep 10, 2013 at 08:13:59PM +0200, azurIt wrote:
> >> >> >On Mon, Sep 09, 2013 at 09:59:17PM +0200, azurIt wrote:
> >> >> >> >On Mon, Sep 09, 2013 at 03:10:10PM +0200, azu
On Tue, Sep 10, 2013 at 11:32:47PM +0200, azurIt wrote:
> >On Tue, Sep 10, 2013 at 11:08:53PM +0200, azurIt wrote:
> >> >On Tue, Sep 10, 2013 at 09:32:53PM +0200, azurIt wrote:
> >> >> Here is full kernel log between 6:00 and 7:59:
> >> >> http://watchdog.sk/lkml/kern6.log
> >> >
> >> >Wow, your ap
On Wed, Sep 11, 2013 at 02:33:05PM +0200, azurIt wrote:
> >On Tue, Sep 10, 2013 at 11:32:47PM +0200, azurIt wrote:
> >> >On Tue, Sep 10, 2013 at 11:08:53PM +0200, azurIt wrote:
> >> >> >On Tue, Sep 10, 2013 at 09:32:53PM +0200, azurIt wrote:
> >> >> >> Here is full kernel log between 6:00 and 7:59:
On Wed, Sep 11, 2013 at 08:54:48PM +0200, azurIt wrote:
> >On Wed, Sep 11, 2013 at 02:33:05PM +0200, azurIt wrote:
> >> >On Tue, Sep 10, 2013 at 11:32:47PM +0200, azurIt wrote:
> >> >> >On Tue, Sep 10, 2013 at 11:08:53PM +0200, azurIt wrote:
> >> >> >> >On Tue, Sep 10, 2013 at 09:32:53PM +0200, azu
On Wed, Sep 11, 2013 at 09:41:18PM +0200, azurIt wrote:
> >On Wed, Sep 11, 2013 at 08:54:48PM +0200, azurIt wrote:
> >> >On Wed, Sep 11, 2013 at 02:33:05PM +0200, azurIt wrote:
> >> >> >On Tue, Sep 10, 2013 at 11:32:47PM +0200, azurIt wrote:
> >> >> >> >On Tue, Sep 10, 2013 at 11:08:53PM +0200, azu
On Mon, Sep 09, 2013 at 02:56:59PM +0200, Michal Hocko wrote:
> [Adding Glauber - the full patch is here https://lkml.org/lkml/2013/9/5/319]
>
> On Mon 09-09-13 14:36:25, Michal Hocko wrote:
> > On Thu 05-09-13 12:18:17, Johannes Weiner wrote:
> > [...]
> > > From:
1 - 100 of 3033 matches
Mail list logo
