Messages in this thread Patch in this message | | | Date | Mon, 28 Jan 2019 10:16:27 +0100 | From | Jan Kara <> | Subject | Re: [regression -next0117] What is kcompactd and why is he eating 100% of my cpu? |
| |
On Sun 27-01-19 16:36:34, valdis.kletnieks@vt.edu wrote: > On Sun, 27 Jan 2019 17:00:27 +0100, Pavel Machek said: > > > > I've noticed this as well on earlier kernels (next-20181224 to 20190115) > > > > Some more info: > > > > 1) echo 3 > /proc/sys/vm/drop_caches unwedges kcompactd in 1-3 seconds. > > > This aspect is curious as it indicates that kcompactd could potentially > > > be infinite looping but it's not something I've experienced myself. By > > > any chance is there a preditable reproduction case for this? > > > > I seen it exactly once, so not sure how reproducible this is. x86-32 > > machine, running chromium browser, so yes, there was some swapping > > involved. > > I don't have a surefire replicator, but my laptop (x86_64, so it's not a 32-bit > only issue) triggers it fairly often, up to multiple times a day. Doesn't seem to > be just the Chrome browser that triggers it - usually I'm doing other stuff as > well, like a compile or similar. The fact that 'drop_caches' clears it makes me > wonder if we're hitting a corner case where cache data isn't being automatically > cleared and clogging something up.
So my buffer_migrate_page_norefs() is certainly buggy in its current incarnation (as a result block device page cache is not migratable at all). I've sent Andrew a patch over week ago but so far it got ignored. The patch is attached, can you give it a try whether it changes something for you? Thanks!
Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR From 59ab3a8504c35e2215af6c251bdb2a8a1caca1dd Mon Sep 17 00:00:00 2001 From: Jan Kara <jack@suse.cz> Date: Wed, 16 Jan 2019 11:02:48 +0100 Subject: [PATCH] mm: migrate: Make buffer_migrate_page_norefs() actually succeed
Currently, buffer_migrate_page_norefs() was constantly failing because buffer_migrate_lock_buffers() grabbed reference on each buffer. In fact, there's no reason for buffer_migrate_lock_buffers() to grab any buffer references as the page is locked during all our operation and thus nobody can reclaim buffers from the page. So remove grabbing of buffer references which also makes buffer_migrate_page_norefs() succeed.
Fixes: 89cb0888ca14 "mm: migrate: provide buffer_migrate_page_norefs()" Signed-off-by: Jan Kara <jack@suse.cz> --- mm/migrate.c | 5 ----- 1 file changed, 5 deletions(-)
Andrew, can you please merge this patch? Sadly my previous testing only tested that page migration in general didn't get broken but I forgot to test whether the new migrate page callback actually results in more successful migrations for block device pages. So the bug got only revealed by customer testing. Now I've reproduced the workload internally and verified that the patch indeed fixes the issue.
diff --git a/mm/migrate.c b/mm/migrate.c index a16b15090df3..712b231a7376 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -709,7 +709,6 @@ static bool buffer_migrate_lock_buffers(struct buffer_head *head, /* Simple case, sync compaction */ if (mode != MIGRATE_ASYNC) { do { - get_bh(bh); lock_buffer(bh); bh = bh->b_this_page; @@ -720,18 +719,15 @@ static bool buffer_migrate_lock_buffers(struct buffer_head *head, /* async case, we cannot block on lock_buffer so use trylock_buffer */ do { - get_bh(bh); if (!trylock_buffer(bh)) { /* * We failed to lock the buffer and cannot stall in * async migration. Release the taken locks */ struct buffer_head *failed_bh = bh; - put_bh(failed_bh); bh = head; while (bh != failed_bh) { unlock_buffer(bh); - put_bh(bh); bh = bh->b_this_page; } return false; @@ -818,7 +814,6 @@ static int __buffer_migrate_page(struct address_space *mapping, bh = head; do { unlock_buffer(bh); - put_bh(bh); bh = bh->b_this_page; } while (bh != head); -- 2.16.4
| |