headers
KOSAKI Motohiro | 1 Jan 2010 10:45
Favicon

[PATCH] mm, lockdep: annotate reclaim context to zone reclaim too

Commit cf40bd16fd (lockdep: annotate reclaim context) introduced reclaim
context annotation. But it didn't annotate zone reclaim. This patch do it.

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro <at> jp.fujitsu.com>
---
 mm/vmscan.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 2bbee91..a039e78 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
 <at>  <at>  -2547,6 +2547,7  <at>  <at>  static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order)
 	 * and RECLAIM_SWAP.
 	 */
 	p->flags |= PF_MEMALLOC | PF_SWAPWRITE;
+	lockdep_set_current_reclaim_state(gfp_mask);
 	reclaim_state.reclaimed_slab = 0;
 	p->reclaim_state = &reclaim_state;

 <at>  <at>  -2590,6 +2591,7  <at>  <at>  static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order)

 	p->reclaim_state = NULL;
 	current->flags &= ~(PF_MEMALLOC | PF_SWAPWRITE);
+	lockdep_clear_current_reclaim_state();
 	return sc.nr_reclaimed >= nr_pages;
 }

--

-- 
1.6.6
(Continue reading)

Permalink | Reply | 6 comments |
headers
Rik van Riel | 1 Jan 2010 15:55
Picon
Favicon

Re: [PATCH 2/4] vmscan: get_scan_ratio cleanup

On 12/28/2009 02:48 AM, KOSAKI Motohiro wrote:
> The get_scan_ratio() should have all scan-ratio related calculations.
> Thus, this patch move some calculation into get_scan_ratio.
>
> Signed-off-by: KOSAKI Motohiro<kosaki.motohiro <at> jp.fujitsu.com>

Reviewed-by: Rik van Riel <riel <at> redhat.com>

--

-- 
All rights reversed.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 0 comments |
headers
Rik van Riel | 1 Jan 2010 15:59
Picon
Favicon

Re: [PATCH 3/4] vmstat: add anon_scan_ratio field to zoneinfo

On 12/28/2009 02:48 AM, KOSAKI Motohiro wrote:
> Vmscan folks was asked "why does my system makes so much swap-out?"
> in lkml at several times.
> At that time, I made the debug patch to show recent_anon_{scanned/rorated}
> parameter at least three times.
>
> Thus, its parameter should be showed on /proc/zoneinfo. It help
> vmscan folks debugging.
>
> Signed-off-by: KOSAKI Motohiro<kosaki.motohiro <at> jp.fujitsu.com>

Reviewed-by: Rik van Riel <riel <at> redhat.com>

--

-- 
All rights reversed.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 0 comments |
headers
Peter Zijlstra | 2 Jan 2010 00:19
Favicon

Re: [PATCH] mm, lockdep: annotate reclaim context to zone reclaim too

On Fri, 2010-01-01 at 18:45 +0900, KOSAKI Motohiro wrote:
> Commit cf40bd16fd (lockdep: annotate reclaim context) introduced reclaim
> context annotation. But it didn't annotate zone reclaim. This patch do it.

And yet you didn't CC anyone involved in that patch, nor explain why you
think it necessary, massive FAIL.

The lockdep annotations cover all of kswapd() and direct reclaim through
__alloc_pages_direct_reclaim(). So why would you need an explicit
annotation in __zone_reclaim()?

> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro <at> jp.fujitsu.com>
> ---
>  mm/vmscan.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 2bbee91..a039e78 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
>  <at>  <at>  -2547,6 +2547,7  <at>  <at>  static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order)
>  	 * and RECLAIM_SWAP.
>  	 */
>  	p->flags |= PF_MEMALLOC | PF_SWAPWRITE;
> +	lockdep_set_current_reclaim_state(gfp_mask);
>  	reclaim_state.reclaimed_slab = 0;
>  	p->reclaim_state = &reclaim_state;
>  
>  <at>  <at>  -2590,6 +2591,7  <at>  <at>  static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order)
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
KOSAKI Motohiro | 2 Jan 2010 06:21
Favicon

Re: [PATCH] mm, lockdep: annotate reclaim context to zone reclaim too

2010/1/2 Peter Zijlstra <peterz <at> infradead.org>:
> On Fri, 2010-01-01 at 18:45 +0900, KOSAKI Motohiro wrote:
>> Commit cf40bd16fd (lockdep: annotate reclaim context) introduced reclaim
>> context annotation. But it didn't annotate zone reclaim. This patch do it.
>
> And yet you didn't CC anyone involved in that patch, nor explain why you
> think it necessary, massive FAIL.
>
> The lockdep annotations cover all of kswapd() and direct reclaim through
> __alloc_pages_direct_reclaim(). So why would you need an explicit
> annotation in __zone_reclaim()?

Thanks CCing. The point is zone-reclaim doesn't use
__alloc_pages_direct_reclaim.
current call graph is

__alloc_pages_nodemask
    get_page_from_freelist
        zone_reclaim()
    __alloc_pages_slowpath
        __alloc_pages_direct_reclaim
            try_to_free_pages

Actually, if zone_reclaim_mode=1, VM never call
__alloc_pages_direct_reclaim in usual VM pressure.
Thus I think zone-reclaim should be annotated explicitly too.
I know almost user don't use zone reclaim mode. but explicit
annotation doesn't have any demerit, I think.

Am I missing anything?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Peter Zijlstra | 2 Jan 2010 11:46
Favicon

Re: [PATCH] mm, lockdep: annotate reclaim context to zone reclaim too

On Sat, 2010-01-02 at 14:21 +0900, KOSAKI Motohiro wrote:
> 2010/1/2 Peter Zijlstra <peterz <at> infradead.org>:
> > On Fri, 2010-01-01 at 18:45 +0900, KOSAKI Motohiro wrote:
> >> Commit cf40bd16fd (lockdep: annotate reclaim context) introduced reclaim
> >> context annotation. But it didn't annotate zone reclaim. This patch do it.
> >
> > And yet you didn't CC anyone involved in that patch, nor explain why you
> > think it necessary, massive FAIL.
> >
> > The lockdep annotations cover all of kswapd() and direct reclaim through
> > __alloc_pages_direct_reclaim(). So why would you need an explicit
> > annotation in __zone_reclaim()?
> 
> Thanks CCing. The point is zone-reclaim doesn't use
> __alloc_pages_direct_reclaim.
> current call graph is
> 
> __alloc_pages_nodemask
>     get_page_from_freelist
>         zone_reclaim()
>     __alloc_pages_slowpath
>         __alloc_pages_direct_reclaim
>             try_to_free_pages
> 
> Actually, if zone_reclaim_mode=1, VM never call
> __alloc_pages_direct_reclaim in usual VM pressure.
> Thus I think zone-reclaim should be annotated explicitly too.
> I know almost user don't use zone reclaim mode. but explicit
> annotation doesn't have any demerit, I think.
(Continue reading)

Permalink | Reply | 3 comments |
headers
KOSAKI Motohiro | 2 Jan 2010 14:29
Favicon

Re: [PATCH] mm, lockdep: annotate reclaim context to zone reclaim too

2010/1/2 Peter Zijlstra <peterz <at> infradead.org>:
> On Sat, 2010-01-02 at 14:21 +0900, KOSAKI Motohiro wrote:
>> 2010/1/2 Peter Zijlstra <peterz <at> infradead.org>:
>> > On Fri, 2010-01-01 at 18:45 +0900, KOSAKI Motohiro wrote:
>> >> Commit cf40bd16fd (lockdep: annotate reclaim context) introduced reclaim
>> >> context annotation. But it didn't annotate zone reclaim. This patch do it.
>> >
>> > And yet you didn't CC anyone involved in that patch, nor explain why you
>> > think it necessary, massive FAIL.
>> >
>> > The lockdep annotations cover all of kswapd() and direct reclaim through
>> > __alloc_pages_direct_reclaim(). So why would you need an explicit
>> > annotation in __zone_reclaim()?
>>
>> Thanks CCing. The point is zone-reclaim doesn't use
>> __alloc_pages_direct_reclaim.
>> current call graph is
>>
>> __alloc_pages_nodemask
>>     get_page_from_freelist
>>         zone_reclaim()
>>     __alloc_pages_slowpath
>>         __alloc_pages_direct_reclaim
>>             try_to_free_pages
>>
>> Actually, if zone_reclaim_mode=1, VM never call
>> __alloc_pages_direct_reclaim in usual VM pressure.
>> Thus I think zone-reclaim should be annotated explicitly too.
>> I know almost user don't use zone reclaim mode. but explicit
>> annotation doesn't have any demerit, I think.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Zijlstra | 2 Jan 2010 15:45
Favicon

Re: [PATCH] mm, lockdep: annotate reclaim context to zone reclaim too

On Sat, 2010-01-02 at 22:29 +0900, KOSAKI Motohiro wrote:

> When recursive annotation occur?

Dunno, I told you you'd have to make sure it doesn't.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 1 comment |
headers
KOSAKI Motohiro | 2 Jan 2010 16:09
Favicon

Re: [PATCH] mm, lockdep: annotate reclaim context to zone reclaim too

2010/1/2 Peter Zijlstra <peterz <at> infradead.org>:
> On Sat, 2010-01-02 at 22:29 +0900, KOSAKI Motohiro wrote:
>
>> When recursive annotation occur?
>
> Dunno, I told you you'd have to make sure it doesn't.

Please see PF_MEMALLOC turning on/off operation points. all
PF_MEMALLOC turing on point prevent recersive already.
(because, otherwise we lost PF_MEMALLOC and makes deadlock...)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>
Permalink | Reply | 0 comments |
headers
Peter Zijlstra | 2 Jan 2010 17:14
Favicon

Re: [RFC PATCH] asynchronous page fault.

On Mon, 2009-12-28 at 11:40 +0100, Peter Zijlstra wrote:

> > Right, so acquiring the PTE lock will either instantiate page tables for
> > a non-existing vma, leaving you with an interesting mess to clean up, or
> > you can also RCU free the page tables (in the same RCU domain as the
> > vma) which will mostly[*] avoid that issue.
> > 
> > [ To make live really really interesting you could even re-use the
> >   page-tables and abort the RCU free when the region gets re-mapped
> >   before the RCU callbacks happen, this will avoid a free/alloc cycle
> >   for fast remapping workloads. ]
> > 
> > Once you hold the PTE lock, you can validate the vma you looked up,
> > since ->unmap() syncs against it. If at that time you find the
> > speculative vma is dead, you fail and re-try the fault.
> > 
> > [*] there still is the case of faulting on an address that didn't
> > previously have page-tables hence the unmap page table scan will have
> > skipped it -- my hacks simply leaked page tables here, but the idea was
> > to acquire the mmap_sem for reading and cleanup properly.
> 
> Alternatively, we could mark vma's dead in some way before we do the
> unmap, then whenever we hit the page-table alloc path, we check against
> the speculative vma and bail if it died.
> 
> That might just work.. will need to ponder it a bit more.

Right, so I don't think we need RCU page tables on x86. All we need is
some extension to the fast_gup() stuff.
(Continue reading)

Permalink | Reply | 6 comments |

Gmane