Merge pull request #1428 from ttttyy/main

fix  edition2@post-11 Chinese translation error

blog/content/edition-2/posts/11-allocator-designs/index.zh-CN.md

@@ -369,7 +369,7 @@ fn align_up(addr: usize, align: usize) -> usize {
 [bitwise `NOT`]: https://en.wikipedia.org/wiki/Bitwise_operation#NOT
 [bitwise `AND`]: https://en.wikipedia.org/wiki/Bitwise_operation#AND
 
-你选择使用哪一个变体，这取决于你。这两种方法计算的结果相同，只是使用不同的方法。
+你选择使用哪一个变体，这取决于你。它们计算的结果相同，只是使用的方法不同。
 
 ### 用法
                                  
@@ -836,7 +836,7 @@ many_boxes_long_lived... [ok]
 
 ### 讨论
 
-和bump分配器相比，链表分配器更适合于作为一个通用分配器，主要是因为它可以直接重用已释放的内存。然而，它也有一些缺点，一部分是由于我们的基础实现所致，另一部分则是由于分配器设计本身的缺陷。
+和bump分配器相比，链表分配器更适合作为一个通用分配器，主要是因为它可以直接重用已释放的内存。然而，它也有一些缺点，一部分是由于我们的基础实现所致，另一部分则是由于分配器设计本身的缺陷。
 
 #### 合并已释放的内存块 {#merge-free-blocks}
 
@@ -865,13 +865,13 @@ many_boxes_long_lived... [ok]
 
 值得强调的是，相比于我们基础的实现而言，链表方法本身的缺陷才是造成性能问题的主要原因。因为在内核级代码中分配性能相当重要，所以我们将在下文中探索第三种通过降低内存使用率换取性能提升的分配器设计。
 
-固定大小块分配器
+## 固定大小块分配器
 
 接下来，我们展示一种使用固定大小的内存块来满足分配请求的分配器设计。使用这种方法，分配器往往会返回比实际需要更大的内存块，这将会由于 [内部碎片][internal fragmentation] 导致浪费内存，但它会显著减少寻找合适的内存块的时间（相比链表分配器而言），从而获得更好的分配性能。
 
 ### 介绍
 
-_固定大小分配器_ 背后的思想如下：我们不再精确分配请求所需的内存大小，而是定义一个固定的块大小列表，并且将每个分配向上取整为列表中的下一个内存块大小。例如，对于 16、64 和 512 的块大小，一个 4 字节的分配将返回一个 16 字节的块，一个 48 字节的分配将返回一个 64 字节的块，一个 128 字节的分配将返回一个 512 字节的块。
+_固定大小块分配器_ 背后的思想如下：我们不再精确分配请求所需的内存大小，而是定义一个固定的块大小列表，并且将每个分配向上取整为列表中的下一个内存块大小。例如，对于 16、64 和 512 的块大小，一个 4 字节的分配将返回一个 16 字节的块，一个 48 字节的分配将返回一个 64 字节的块，一个 128 字节的分配将返回一个 512 字节的块。
 
 
 和链表分配器相同，我们通过在未使用的内存区域中创建链表来跟踪未使用的内存。然而，不再使用单一链表管理不同尺块大小的内存区域，而是为每个尺寸类别创建一个单独的链表。每个列表只存储相同大小的块。例如，对于块大小为 16、64 和 512 的情况，内存中会存在三个单独的链表：