diff for duplicates of <20170718191527.GA4009@destiny> diff --git a/a/1.txt b/N1/1.txt index a0262c6..3e366f4 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -40,8 +40,8 @@ On Sat, Jul 15, 2017 at 10:23:05PM -0400, Dennis Zhou wrote: > There is one caveat with this implementation. In an effort to make freeing > fast, the only time metadata is updated on the free path is if a whole > block becomes free or the freed area spans across metadata blocks. This -> causes the chunka??s contig_hint to be potentially smaller than what it -> could allocate by up to a block. If the chunka??s contig_hint is smaller +> causes the chunk’s contig_hint to be potentially smaller than what it +> could allocate by up to a block. If the chunk’s contig_hint is smaller > than a block, a check occurs and the hint is kept accurate. Metadata is > always kept accurate on allocation and therefore the situation where a > chunk has a larger contig_hint than available will never occur. @@ -98,9 +98,3 @@ And lastly, why are we paying a 2x latency cost? What is it about the bitmap allocator that makes it much worse than the area map allocator? Thanks, Josef - --- -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/N1/content_digest index 2ecdc6e..f4a3459 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -53,8 +53,8 @@ "> There is one caveat with this implementation. In an effort to make freeing\n" "> fast, the only time metadata is updated on the free path is if a whole\n" "> block becomes free or the freed area spans across metadata blocks. This\n" - "> causes the chunka??s contig_hint to be potentially smaller than what it\n" - "> could allocate by up to a block. If the chunka??s contig_hint is smaller\n" + "> causes the chunk\342\200\231s contig_hint to be potentially smaller than what it\n" + "> could allocate by up to a block. If the chunk\342\200\231s contig_hint is smaller\n" "> than a block, a check occurs and the hint is kept accurate. Metadata is\n" "> always kept accurate on allocation and therefore the situation where a\n" "> chunk has a larger contig_hint than available will never occur.\n" @@ -110,12 +110,6 @@ "And lastly, why are we paying a 2x latency cost? What is it about the bitmap\n" "allocator that makes it much worse than the area map allocator? Thanks,\n" "\n" - "Josef\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>" + Josef -df130f960b9fff0e7f78dd95f914a69dc70401339aca784bb3f63e294e376f14 +a3c5c66186f82677afc0b9bf2ef030e639663338a63e72e7224c6bcb20739515
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.