diff for duplicates of <20110316131324.GM2140@cmpxchg.org> diff --git a/a/1.txt b/N1/1.txt index f773f73..c24f312 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -91,7 +91,3 @@ further narrow writeback to the right pages - iff shared big files become a problem. Does that sound feasible? --- -To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index f12875b..a6ab709 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -118,10 +118,6 @@ "further narrow writeback to the right pages - iff shared big files\n" "become a problem.\n" "\n" - "Does that sound feasible?\n" - "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-fsdevel\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + Does that sound feasible? -24c00a653d1a16cd7580f1ce5d0c2f8bc0dc5491a6f0163a76075be81bc428b3 +e4e5665dc54297ed2038a3363570cb25c685d664424aa840e484f64f0735c935
diff --git a/a/1.txt b/N2/1.txt index f773f73..709f526 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -5,18 +5,18 @@ On Tue, Mar 15, 2011 at 02:48:39PM -0400, Vivek Goyal wrote: > > > > > > [..] > > >> > We could just crawl the memcg's page LRU and bring things under control -> > >> > that way, couldn't we? That would fix it. What were the reasons for +> > >> > that way, couldn't we? That would fix it. What were the reasons for > > >> > not doing this? > > >> -> > >> My rational for pursuing bdi writeback was I/O locality. I have heard that -> > >> per-page I/O has bad locality. Per inode bdi-style writeback should have better +> > >> My rational for pursuing bdi writeback was I/O locality. I have heard that +> > >> per-page I/O has bad locality. Per inode bdi-style writeback should have better > > >> locality. > > >> > > >> My hunch is the best solution is a hybrid which uses a) bdi writeback with a > > >> target memcg filter and b) using the memcg lru as a fallback to identify the bdi -> > >> that needed writeback. I think the part a) memcg filtering is likely something +> > >> that needed writeback. I think the part a) memcg filtering is likely something > > >> like: -> > >> http://marc.info/?l=linux-kernel&m=129910424431837 +> > >> http://marc.info/?l=linux-kernel&m=129910424431837 > > >> > > >> The part b) bdi selection should not be too hard assuming that page-to-mapping > > >> locking is doable. @@ -91,7 +91,10 @@ further narrow writeback to the right pages - iff shared big files become a problem. Does that sound feasible? + -- -To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in -the body of a message to majordomo@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html +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 internet charges in Canada: sign http://stopthemeter.ca/ +Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> diff --git a/a/content_digest b/N2/content_digest index f12875b..1c2d19a 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -33,18 +33,18 @@ "> > >\n" "> > > [..]\n" "> > >> > We could just crawl the memcg's page LRU and bring things under control\n" - "> > >> > that way, couldn't we? \302\240That would fix it. \302\240What were the reasons for\n" + "> > >> > that way, couldn't we? That would fix it. What were the reasons for\n" "> > >> > not doing this?\n" "> > >>\n" - "> > >> My rational for pursuing bdi writeback was I/O locality. \302\240I have heard that\n" - "> > >> per-page I/O has bad locality. \302\240Per inode bdi-style writeback should have better\n" + "> > >> My rational for pursuing bdi writeback was I/O locality. I have heard that\n" + "> > >> per-page I/O has bad locality. Per inode bdi-style writeback should have better\n" "> > >> locality.\n" "> > >>\n" "> > >> My hunch is the best solution is a hybrid which uses a) bdi writeback with a\n" "> > >> target memcg filter and b) using the memcg lru as a fallback to identify the bdi\n" - "> > >> that needed writeback. \302\240I think the part a) memcg filtering is likely something\n" + "> > >> that needed writeback. I think the part a) memcg filtering is likely something\n" "> > >> like:\n" - "> > >> \302\240http://marc.info/?l=linux-kernel&m=129910424431837\n" + "> > >> http://marc.info/?l=linux-kernel&m=129910424431837\n" "> > >>\n" "> > >> The part b) bdi selection should not be too hard assuming that page-to-mapping\n" "> > >> locking is doable.\n" @@ -119,9 +119,12 @@ "become a problem.\n" "\n" "Does that sound feasible?\n" + "\n" "--\n" - "To unsubscribe from this list: send the line \"unsubscribe linux-fsdevel\" in\n" - "the body of a message to majordomo@vger.kernel.org\n" - More majordomo info at http://vger.kernel.org/majordomo-info.html + "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" + "the body to majordomo@kvack.org. For more info on Linux MM,\n" + "see: http://www.linux-mm.org/ .\n" + "Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/\n" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -24c00a653d1a16cd7580f1ce5d0c2f8bc0dc5491a6f0163a76075be81bc428b3 +9020d672edfbe2cf15cfd82ceead4a51c4a033d9f6eb974938d63ac92183bc54
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.