diff for duplicates of <20131105041245.GY6188@dastard> diff --git a/a/1.txt b/N1/1.txt index b4c12a0..ae0ae7d 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -4,7 +4,7 @@ On Mon, Nov 04, 2013 at 05:50:13PM -0700, Andreas Dilger wrote: > > On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov <t.artem@lycos.com> wrote: > >> > >> On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11 -> >> kernel built for the i686 (with PAE) and x86-64 architectures. What’s +> >> kernel built for the i686 (with PAE) and x86-64 architectures. Whata??s > >> really troubling me is that the x86-64 kernel has the following problem: > >> > >> When I copy large files to any storage device, be it my HDD with ext4 @@ -26,15 +26,15 @@ On Mon, Nov 04, 2013 at 05:50:13PM -0700, Andreas Dilger wrote: > > much care), and the fact that x86-32 ends up having much lower limits > > even if you end up having more memory. > -> I think the “delay writes for a long time” is a holdover from the +> I think the a??delay writes for a long timea?? is a holdover from the > days when e.g. /tmp was on a disk and compilers had lousy IO > patterns, then they deleted the file. Today, /tmp is always in -> RAM, and IMHO the “write and delete” workload tested by dbench +> RAM, and IMHO the a??write and deletea?? workload tested by dbench > is not worthwhile optimizing for. > -> With Lustre, we’ve long taken the approach that if there is enough +> With Lustre, wea??ve long taken the approach that if there is enough > dirty data on a file to make a decent write (which is around 8MB -> today even for very fast storage) then there isn’t much point to +> today even for very fast storage) then there isna??t much point to > hold back for more data before starting the IO. Agreed - write-through caching is much better for high throughput @@ -84,9 +84,9 @@ faster. Similarly, I've seen other workloads where the writeback delay results in files that can be *read* orders of magnitude faster.... -> Something simple like “start writing at 16MB dirty on a single file” +> Something simple like a??start writing at 16MB dirty on a single filea?? > would probably avoid a lot of complexity at little real-world cost. -> That shouldn’t throttle dirtying memory above 16MB, but just start +> That shouldna??t throttle dirtying memory above 16MB, but just start > writeout much earlier than it does today. That doesn't solve the "slow device, large file" problem. We can diff --git a/a/content_digest b/N1/content_digest index e161fdd..dad8a1a 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -21,7 +21,7 @@ "> > On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov <t.artem@lycos.com> wrote:\n" "> >> \n" "> >> On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11\n" - "> >> kernel built for the i686 (with PAE) and x86-64 architectures. What\342\200\231s\n" + "> >> kernel built for the i686 (with PAE) and x86-64 architectures. Whata??s\n" "> >> really troubling me is that the x86-64 kernel has the following problem:\n" "> >> \n" "> >> When I copy large files to any storage device, be it my HDD with ext4\n" @@ -43,15 +43,15 @@ "> > much care), and the fact that x86-32 ends up having much lower limits\n" "> > even if you end up having more memory.\n" "> \n" - "> I think the \342\200\234delay writes for a long time\342\200\235 is a holdover from the\n" + "> I think the a??delay writes for a long timea?? is a holdover from the\n" "> days when e.g. /tmp was on a disk and compilers had lousy IO\n" "> patterns, then they deleted the file. Today, /tmp is always in\n" - "> RAM, and IMHO the \342\200\234write and delete\342\200\235 workload tested by dbench\n" + "> RAM, and IMHO the a??write and deletea?? workload tested by dbench\n" "> is not worthwhile optimizing for.\n" "> \n" - "> With Lustre, we\342\200\231ve long taken the approach that if there is enough\n" + "> With Lustre, wea??ve long taken the approach that if there is enough\n" "> dirty data on a file to make a decent write (which is around 8MB\n" - "> today even for very fast storage) then there isn\342\200\231t much point to\n" + "> today even for very fast storage) then there isna??t much point to\n" "> hold back for more data before starting the IO.\n" "\n" "Agreed - write-through caching is much better for high throughput\n" @@ -101,9 +101,9 @@ "delay results in files that can be *read* orders of magnitude\n" "faster....\n" "\n" - "> Something simple like \342\200\234start writing at 16MB dirty on a single file\342\200\235\n" + "> Something simple like a??start writing at 16MB dirty on a single filea??\n" "> would probably avoid a lot of complexity at little real-world cost.\n" - "> That shouldn\342\200\231t throttle dirtying memory above 16MB, but just start\n" + "> That shouldna??t throttle dirtying memory above 16MB, but just start\n" "> writeout much earlier than it does today.\n" "\n" "That doesn't solve the \"slow device, large file\" problem. We can\n" @@ -199,4 +199,4 @@ "see: http://www.linux-mm.org/ .\n" "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -276229f484e8ebc7da9177c86cc6af4b29e9b2e210a0d7e2a63c586955a44b93 +6e5067e0e725fcb94b3e52a0b44044e9dee8fd71a8f76fbfd1abd1b629ed471f
diff --git a/a/1.txt b/N2/1.txt index b4c12a0..6080873 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -175,9 +175,3 @@ Dave. -- Dave Chinner david@fromorbit.com - --- -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> diff --git a/a/content_digest b/N2/content_digest index e161fdd..48b8d70 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -191,12 +191,6 @@ "Dave.\n" "-- \n" "Dave Chinner\n" - "david@fromorbit.com\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" - "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" + david@fromorbit.com -276229f484e8ebc7da9177c86cc6af4b29e9b2e210a0d7e2a63c586955a44b93 +f7544bde6027573358d50fd6b430eadb7c0663994f0b0ee7726779e9de7e734e
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.