From: Seth Jennings <sjenning@linux.vnet.ibm.com>
To: Dave Hansen <dave@sr71.net>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, mgorman@suse.de,
tim.c.chen@linux.intel.com
Subject: Re: [RFC][PATCH 1/7] defer clearing of page_private() for swap cache pages
Date: Thu, 9 May 2013 17:07:39 -0500 [thread overview]
Message-ID: <20130509220739.GA14840@cerebellum> (raw)
In-Reply-To: <20130507211955.7DF88A4F@viggo.jf.intel.com>
On Tue, May 07, 2013 at 02:19:55PM -0700, Dave Hansen wrote:
>
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> There are only two callers of swapcache_free() which actually
> pass in a non-NULL 'struct page'. Both of them
> (__remove_mapping and delete_from_swap_cache()) create a
> temporary on-stack 'swp_entry_t' and set entry.val to
> page_private().
>
> They need to do this since __delete_from_swap_cache() does
> set_page_private(page, 0) and destroys the information.
>
> However, I'd like to batch a few of these operations on several
> pages together in a new version of __remove_mapping(), and I
> would prefer not to have to allocate temporary storage for
> each page. The code is pretty ugly, and it's a bit silly
> to create these on-stack 'swp_entry_t's when it is so easy to
> just keep the information around in 'struct page'.
>
> There should not be any danger in doing this since we are
> absolutely on the path of freeing these page. There is no
> turning back, and no other rerferences can be obtained
> after it comes out of the radix tree.
I get a BUG on this one:
[ 26.114818] ------------[ cut here ]------------
[ 26.115282] kernel BUG at mm/memcontrol.c:4111!
[ 26.115282] invalid opcode: 0000 [#1] PREEMPT SMP
[ 26.115282] Modules linked in:
[ 26.115282] CPU: 3 PID: 5026 Comm: cc1 Not tainted 3.9.0+ #8
[ 26.115282] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 26.115282] task: ffff88007c1cdca0 ti: ffff88001b442000 task.ti: ffff88001b442000
[ 26.115282] RIP: 0010:[<ffffffff810ed425>] [<ffffffff810ed425>] __mem_cgroup_uncharge_common+0x255/0x2e0
[ 26.115282] RSP: 0000:ffff88001b443708 EFLAGS: 00010206
[ 26.115282] RAX: 4000000000090009 RBX: 0000000000000000 RCX: ffffc90000014001
[ 26.115282] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffffea00006e5b40
[ 26.115282] RBP: ffff88001b443738 R08: 0000000000000000 R09: 0000000000000000
[ 26.115282] R10: 0000000000000000 R11: 0000000000000000 R12: ffffea00006e5b40
[ 26.115282] R13: 0000000000000000 R14: ffffea00006e5b40 R15: 0000000000000002
[ 26.115282] FS: 00007fabd08ee700(0000) GS:ffff88007fd80000(0000) knlGS:0000000000000000
[ 26.115282] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 26.115282] CR2: 00007fabce27a000 CR3: 000000001985f000 CR4: 00000000000006a0
[ 26.115282] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 26.115282] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 26.115282] Stack:
[ 26.115282] ffffffff810dcbae ffff880064a0a500 0000000000000001 ffffea00006e5b40
[ 26.115282] ffffea00006e5b40 0000000000000001 ffff88001b443748 ffffffff810f0d05
[ 26.115282] ffff88001b443778 ffffffff810ddb3e ffff88001b443778 ffffea00006e5b40
[ 26.115282] Call Trace:
[ 26.115282] [<ffffffff810dcbae>] ? swap_info_get+0x5e/0xe0
[ 26.115282] [<ffffffff810f0d05>] mem_cgroup_uncharge_swapcache+0x15/0x20
[ 26.115282] [<ffffffff810ddb3e>] swapcache_free+0x4e/0x70
[ 26.115282] [<ffffffff810b6e67>] __remove_mapping+0xd7/0x120
[ 26.115282] [<ffffffff810b8682>] shrink_page_list+0x5c2/0x920
[ 26.115282] [<ffffffff810b780e>] ? isolate_lru_pages.isra.37+0xae/0x120
[ 26.115282] [<ffffffff810b8ecf>] shrink_inactive_list+0x13f/0x380
[ 26.115282] [<ffffffff810b9350>] shrink_lruvec+0x240/0x4e0
[ 26.115282] [<ffffffff810b9656>] shrink_zone+0x66/0x1a0
[ 26.115282] [<ffffffff810ba1fb>] do_try_to_free_pages+0xeb/0x570
[ 26.115282] [<ffffffff810eb7d9>] ? lookup_page_cgroup_used+0x9/0x20
[ 26.115282] [<ffffffff810ba7af>] try_to_free_pages+0x9f/0xc0
[ 26.115282] [<ffffffff810b1357>] __alloc_pages_nodemask+0x5a7/0x970
[ 26.115282] [<ffffffff810cb2be>] handle_pte_fault+0x65e/0x880
[ 26.115282] [<ffffffff810cc7d9>] handle_mm_fault+0x139/0x1e0
[ 26.115282] [<ffffffff81027920>] __do_page_fault+0x160/0x460
[ 26.115282] [<ffffffff810d176c>] ? do_brk+0x1fc/0x360
[ 26.115282] [<ffffffff81212979>] ? lockdep_sys_exit_thunk+0x35/0x67
[ 26.115282] [<ffffffff81027c49>] do_page_fault+0x9/0x10
[ 26.115282] [<ffffffff813b4a72>] page_fault+0x22/0x30
[ 26.115282] Code: a9 00 00 08 00 0f 85 43 fe ff ff e9 b8 fe ff ff 66 0f 1f 44 00 00 41 8b 44 24 18 85 c0 0f 89 2b fe ff ff 0f 1f 00 e9 9d fe ff ff <0f> 0b 66 0f 1f 84 00 00 00 00 00 49 89 9c 24 48 0f 00 00 e9 0a
[ 26.115282] RIP [<ffffffff810ed425>] __mem_cgroup_uncharge_common+0x255/0x2e0
[ 26.115282] RSP <ffff88001b443708>
[ 26.171597] ---[ end trace 5e49a21e51452c24 ]---
mm/memcontrol:4111
VM_BUG_ON(PageSwapCache(page));
Seems that mem_cgroup_uncharge_swapcache, somewhat ironically expects the
SwapCache flag to be unset already.
Fix might be a simple as removing that VM_BUG_ON() but there might be more to
it. There usually is :)
Seth
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> ---
>
> linux.git-davehans/mm/swap_state.c | 4 ++--
> linux.git-davehans/mm/vmscan.c | 2 ++
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff -puN mm/swap_state.c~__delete_from_swap_cache-dont-clear-page-private mm/swap_state.c
> --- linux.git/mm/swap_state.c~__delete_from_swap_cache-dont-clear-page-private 2013-05-07 13:48:13.698044473 -0700
> +++ linux.git-davehans/mm/swap_state.c 2013-05-07 13:48:13.703044693 -0700
> @@ -146,8 +146,6 @@ void __delete_from_swap_cache(struct pag
> entry.val = page_private(page);
> address_space = swap_address_space(entry);
> radix_tree_delete(&address_space->page_tree, page_private(page));
> - set_page_private(page, 0);
> - ClearPageSwapCache(page);
> address_space->nrpages--;
> __dec_zone_page_state(page, NR_FILE_PAGES);
> INC_CACHE_INFO(del_total);
> @@ -224,6 +222,8 @@ void delete_from_swap_cache(struct page
> spin_unlock_irq(&address_space->tree_lock);
>
> swapcache_free(entry, page);
> + set_page_private(page, 0);
> + ClearPageSwapCache(page);
> page_cache_release(page);
> }
>
> diff -puN mm/vmscan.c~__delete_from_swap_cache-dont-clear-page-private mm/vmscan.c
> --- linux.git/mm/vmscan.c~__delete_from_swap_cache-dont-clear-page-private 2013-05-07 13:48:13.700044561 -0700
> +++ linux.git-davehans/mm/vmscan.c 2013-05-07 13:48:13.705044783 -0700
> @@ -494,6 +494,8 @@ static int __remove_mapping(struct addre
> __delete_from_swap_cache(page);
> spin_unlock_irq(&mapping->tree_lock);
> swapcache_free(swap, page);
> + set_page_private(page, 0);
> + ClearPageSwapCache(page);
> } else {
> void (*freepage)(struct page *);
>
> _
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-05-09 22:07 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-07 21:19 [RFC][PATCH 0/7] mm: Batch page reclamation under shink_page_list Dave Hansen
2013-05-07 21:19 ` [RFC][PATCH 1/7] defer clearing of page_private() for swap cache pages Dave Hansen
2013-05-09 22:07 ` Seth Jennings [this message]
2013-05-09 22:19 ` Dave Hansen
2013-05-10 9:26 ` Michal Hocko
2013-05-10 14:01 ` Seth Jennings
2013-05-14 14:55 ` Mel Gorman
2013-05-07 21:19 ` [RFC][PATCH 2/7] make 'struct page' and swp_entry_t variants of swapcache_free() Dave Hansen
2013-05-14 15:00 ` Mel Gorman
2013-05-07 21:19 ` [RFC][PATCH 3/7] break up __remove_mapping() Dave Hansen
2013-05-14 15:22 ` Mel Gorman
2013-05-07 21:20 ` [RFC][PATCH 4/7] break out mapping "freepage" code Dave Hansen
2013-05-14 15:26 ` Mel Gorman
2013-05-07 21:20 ` [RFC][PATCH 5/7] create __remove_mapping_batch() Dave Hansen
2013-05-09 22:13 ` Seth Jennings
2013-05-09 22:18 ` Dave Hansen
2013-05-14 15:51 ` Mel Gorman
2013-05-16 17:14 ` Dave Hansen
2013-05-07 21:20 ` [RFC][PATCH 6/7] use __remove_mapping_batch() in shrink_page_list() Dave Hansen
2013-05-14 16:05 ` Mel Gorman
2013-05-14 16:50 ` Dave Hansen
2013-05-07 21:20 ` [RFC][PATCH 7/7] drain batch list during long operations Dave Hansen
2013-05-07 23:56 ` Dave Hansen
2013-05-08 0:42 ` Tim Chen
2013-05-14 16:08 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130509220739.GA14840@cerebellum \
--to=sjenning@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dave@sr71.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=tim.c.chen@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).