diff for duplicates of <20110821141136.GA29660@localhost> diff --git a/a/1.txt b/N1/1.txt index e808181..94ff343 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -113,3 +113,7 @@ Fengguang > > Thanks, > > Fengguang > > +-- +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 ad457c1..aaedf5f 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -137,6 +137,10 @@ "> >\n" "> > Thanks,\n" "> > Fengguang\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 -d231a2b579b807fdbec6f5f14ab219cb53604d8e67ef5e18081802d66e2cc15c +ca686099e1c20036854c22257852633c29b579ff7a22ca16c5d07c8f89fccff2
diff --git a/a/1.txt b/N2/1.txt index e808181..535137a 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -45,19 +45,19 @@ Fengguang > > Thanks. > > > >> Doubts: -> >> i) Your entire implementation seems to be dependent on someone +> >> i) A Your entire implementation seems to be dependent on someone > >> calling balance_dirty_pages() -> >> directly or indirectly. This function will call the +> >> A A A directly or indirectly. This function will call the > >> bdi_start_background_writeback() which wakes -> >> up the flusher thread. -> >> What about those page dirtying code paths which might not call +> >> A A A up the flusher thread. +> >> A A A What about those page dirtying code paths which might not call > >> balance_dirty_pages ? -> >> Those paths then depend on the BDI thread periodically writing it +> >> A A A Those paths then depend on the BDI thread periodically writing it > >> to disk and then we are again -> >> dependent on the writeback interval. -> >> Can we assume that the kernel will reliably call +> >> A A A dependent on the writeback interval. +> >> A A A Can we assume that the kernel will reliably call > >> balance_dirty_pages() whenever the pages -> >> are dirtied ? If that was true, then we would not need bdi +> >> A A A are dirtied ? If that was true, then we would not need bdi > >> periodic writeback threads ever. > > > > Yes. The kernel need a way to limit the total number of dirty pages at @@ -78,13 +78,13 @@ Fengguang > > hence background writeout does not kick in, dirty inodes younger than > > 30s won't be written to disk by the flusher. > > -> >> ii) Even after your rigorous checking, the bdi_writeback_thread() +> >> ii) A Even after your rigorous checking, the bdi_writeback_thread() > >> will still do a schedule_timeout() -> >> with the global value. Will your current solution then handle +> >> A A A with the global value. Will your current solution then handle > >> Artem's disk removal scenario ? -> >> Else, you start using your value in the schedule_timeout() call +> >> A A A Else, you start using your value in the schedule_timeout() call > >> in the bdi_writeback_thread() -> >> function, which brings us back to the interval phenomenon I was +> >> A A A function, which brings us back to the interval phenomenon I was > >> talking about. > > > > wb_writeback() will keep running as long as over_bground_thresh(). @@ -92,8 +92,8 @@ Fengguang > > The flusher will keep writing as long as there are more works, since > > there is a > > -> > if (!list_empty(&bdi->work_list)) -> > continue; +> > A A A A A A A A if (!list_empty(&bdi->work_list)) +> > A A A A A A A A A A A A continue; > > > > before the schedule_timeout() call. > > @@ -113,3 +113,10 @@ Fengguang > > Thanks, > > Fengguang > > + +-- +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 ad457c1..879bcc3 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -70,19 +70,19 @@ "> > Thanks.\n" "> >\n" "> >> Doubts:\n" - "> >> i) \302\240 Your entire implementation seems to be dependent on someone\n" + "> >> i) A Your entire implementation seems to be dependent on someone\n" "> >> calling balance_dirty_pages()\n" - "> >> \302\240 \302\240 \302\240directly or indirectly. This function will call the\n" + "> >> A A A directly or indirectly. This function will call the\n" "> >> bdi_start_background_writeback() which wakes\n" - "> >> \302\240 \302\240 \302\240up the flusher thread.\n" - "> >> \302\240 \302\240 \302\240What about those page dirtying code paths which might not call\n" + "> >> A A A up the flusher thread.\n" + "> >> A A A What about those page dirtying code paths which might not call\n" "> >> balance_dirty_pages ?\n" - "> >> \302\240 \302\240 \302\240Those paths then depend on the BDI thread periodically writing it\n" + "> >> A A A Those paths then depend on the BDI thread periodically writing it\n" "> >> to disk and then we are again\n" - "> >> \302\240 \302\240 \302\240dependent on the writeback interval.\n" - "> >> \302\240 \302\240 \302\240Can we assume that the kernel will reliably call\n" + "> >> A A A dependent on the writeback interval.\n" + "> >> A A A Can we assume that the kernel will reliably call\n" "> >> balance_dirty_pages() whenever the pages\n" - "> >> \302\240 \302\240 \302\240are dirtied ? If that was true, then we would not need bdi\n" + "> >> A A A are dirtied ? If that was true, then we would not need bdi\n" "> >> periodic writeback threads ever.\n" "> >\n" "> > Yes. The kernel need a way to limit the total number of dirty pages at\n" @@ -103,13 +103,13 @@ "> > hence background writeout does not kick in, dirty inodes younger than\n" "> > 30s won't be written to disk by the flusher.\n" "> >\n" - "> >> ii) \302\240Even after your rigorous checking, the bdi_writeback_thread()\n" + "> >> ii) A Even after your rigorous checking, the bdi_writeback_thread()\n" "> >> will still do a schedule_timeout()\n" - "> >> \302\240 \302\240 \302\240with the global value. Will your current solution then handle\n" + "> >> A A A with the global value. Will your current solution then handle\n" "> >> Artem's disk removal scenario ?\n" - "> >> \302\240 \302\240 \302\240Else, you start using your value in the schedule_timeout() call\n" + "> >> A A A Else, you start using your value in the schedule_timeout() call\n" "> >> in the bdi_writeback_thread()\n" - "> >> \302\240 \302\240 \302\240function, which brings us back to the interval phenomenon I was\n" + "> >> A A A function, which brings us back to the interval phenomenon I was\n" "> >> talking about.\n" "> >\n" "> > wb_writeback() will keep running as long as over_bground_thresh().\n" @@ -117,8 +117,8 @@ "> > The flusher will keep writing as long as there are more works, since\n" "> > there is a\n" "> >\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240if (!list_empty(&bdi->work_list))\n" - "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240continue;\n" + "> > A A A A A A A A if (!list_empty(&bdi->work_list))\n" + "> > A A A A A A A A A A A A continue;\n" "> >\n" "> > before the schedule_timeout() call.\n" "> >\n" @@ -137,6 +137,13 @@ "> >\n" "> > Thanks,\n" "> > Fengguang\n" - > > + "> >\n" + "\n" + "--\n" + "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>" -d231a2b579b807fdbec6f5f14ab219cb53604d8e67ef5e18081802d66e2cc15c +364de5fd0ad2b11fe1f1fc4dabe235d0ea494897f3e759013074a560d451cf95
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.