diff for duplicates of <1289847339-sup-4591@think> diff --git a/a/1.txt b/N1/1.txt index 7b558b6..2c2f1ca 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -10,13 +10,12 @@ Excerpts from Andrea Arcangeli's message of 2010-11-15 13:46:57 -0500: > > > + */ > > > + if (PageDirty(page)) > > > + return -EAGAIN; -> > >=20 +> > > > > > fallback_migrate_page would call writeout() which is apparently not > > > ok in btrfs for locking issues leading to corruption. -> >=20 -> > Hmm, it seems the issue for that particular problem is indeedin btrfs= -. ->=20 +> > +> > Hmm, it seems the issue for that particular problem is indeedin btrfs. +> > I've been reading the writeout() in mm/migrate.c and I wonder if maybe > that should have been WB_SYNC_ALL or if we miss a > wait_on_page_writeback in after ->writepage() returns? Can you have a @@ -29,7 +28,7 @@ Excerpts from Andrea Arcangeli's message of 2010-11-15 13:46:57 -0500: It always returns either -EIO or -EAGAIN, so the caller will try again and then end up waiting on PageWriteback? ->=20 +> > > If it needs external locking for writing out data it should not > > implement ->writepage to start with. Chris, can you explain what's > > going on with the btree code? It's pretty funny both in the @@ -37,27 +36,23 @@ and then end up waiting on PageWriteback? > > if PF_MEMALLOC is not set, but otherwise does much more complicated > > work, and also in btree_writepages which skips various WB_SYNC_NONE, > > including the very weird check for for_kupdate. -> >=20 -> > What's the story behing all this and the corruption that Andrea found= -? -> >=20 -> > > > Btw, what codepath does THP call migrate_pages from? If you don'= -t -> > > > use an explicit thread writeout will be a no-op on btrfs and XFS,= - too. -> > >=20 +> > +> > What's the story behing all this and the corruption that Andrea found? +> > +> > > > Btw, what codepath does THP call migrate_pages from? If you don't +> > > > use an explicit thread writeout will be a no-op on btrfs and XFS, too. +> > > > > > THP never calls migrate_pages, it's memory compaction that calls it -> > > from inside alloc_pages(order=3D9). It got noticed only with THP be= -cause +> > > from inside alloc_pages(order=9). It got noticed only with THP because > > > it makes more frequent hugepage allocations than nr_hugepages in > > > hugetlbfs (and maybe there are more THP users already). -> >=20 +> > > > Well, s/THP/compaction/ and the same problem applies. The modern > > filesystem all have stopped from writeback happening either at all > > or at least for the delalloc case from direct reclaim. Calling > > into this code from alloc_pages for filesystem backed pages is thus > > rather pointless. ->=20 +> > Compaction practically only happens in the context of the task > allocating memory (in my tree it is also used by kswapd). Not > immediate to ask a separate daemon to invoke it. Not sure why this @@ -80,4 +75,4 @@ 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/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ -Don't email: <a href=3Dmailto:"dont@kvack.org"> email@kvack.org </a> +Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N1/content_digest index 8472e88..b27d273 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -30,13 +30,12 @@ "> > > + */\n" "> > > + if (PageDirty(page))\n" "> > > + return -EAGAIN;\n" - "> > >=20\n" + "> > > \n" "> > > fallback_migrate_page would call writeout() which is apparently not\n" "> > > ok in btrfs for locking issues leading to corruption.\n" - "> >=20\n" - "> > Hmm, it seems the issue for that particular problem is indeedin btrfs=\n" - ".\n" - ">=20\n" + "> > \n" + "> > Hmm, it seems the issue for that particular problem is indeedin btrfs.\n" + "> \n" "> I've been reading the writeout() in mm/migrate.c and I wonder if maybe\n" "> that should have been WB_SYNC_ALL or if we miss a\n" "> wait_on_page_writeback in after ->writepage() returns? Can you have a\n" @@ -49,7 +48,7 @@ "It always returns either -EIO or -EAGAIN, so the caller will try again\n" "and then end up waiting on PageWriteback?\n" "\n" - ">=20\n" + "> \n" "> > If it needs external locking for writing out data it should not\n" "> > implement ->writepage to start with. Chris, can you explain what's\n" "> > going on with the btree code? It's pretty funny both in the\n" @@ -57,27 +56,23 @@ "> > if PF_MEMALLOC is not set, but otherwise does much more complicated\n" "> > work, and also in btree_writepages which skips various WB_SYNC_NONE,\n" "> > including the very weird check for for_kupdate.\n" - "> >=20\n" - "> > What's the story behing all this and the corruption that Andrea found=\n" - "?\n" - "> >=20\n" - "> > > > Btw, what codepath does THP call migrate_pages from? If you don'=\n" - "t\n" - "> > > > use an explicit thread writeout will be a no-op on btrfs and XFS,=\n" - " too.\n" - "> > >=20\n" + "> > \n" + "> > What's the story behing all this and the corruption that Andrea found?\n" + "> > \n" + "> > > > Btw, what codepath does THP call migrate_pages from? If you don't\n" + "> > > > use an explicit thread writeout will be a no-op on btrfs and XFS, too.\n" + "> > > \n" "> > > THP never calls migrate_pages, it's memory compaction that calls it\n" - "> > > from inside alloc_pages(order=3D9). It got noticed only with THP be=\n" - "cause\n" + "> > > from inside alloc_pages(order=9). It got noticed only with THP because\n" "> > > it makes more frequent hugepage allocations than nr_hugepages in\n" "> > > hugetlbfs (and maybe there are more THP users already).\n" - "> >=20\n" + "> > \n" "> > Well, s/THP/compaction/ and the same problem applies. The modern\n" "> > filesystem all have stopped from writeback happening either at all\n" "> > or at least for the delalloc case from direct reclaim. Calling\n" "> > into this code from alloc_pages for filesystem backed pages is thus\n" "> > rather pointless.\n" - ">=20\n" + "> \n" "> Compaction practically only happens in the context of the task\n" "> allocating memory (in my tree it is also used by kswapd). Not\n" "> immediate to ask a separate daemon to invoke it. Not sure why this\n" @@ -100,6 +95,6 @@ "the body to majordomo@kvack.org. For more info on Linux MM,\n" "see: http://www.linux-mm.org/ .\n" "Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/\n" - "Don't email: <a href=3Dmailto:\"dont@kvack.org\"> email@kvack.org </a>" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -1492eebf1cba6f1f3d8a1b62c841f3885fcfca401982e4a486e0c90a2f632ad8 +16762a87d5104c54c115d184b0483060e82490fec79bf5d5bc75051806ca798d
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.