By: ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com), June 30, 2022 10:40 am
Room: Moderated Discussions
Adrian (a.delete@this.acm.org) on June 30, 2022 8:31 am wrote:
> Foo_ (foo.delete@this.nomail.com) on June 30, 2022 7:43 am wrote:
> > Adrian (a.delete@this.acm.org) on June 30, 2022 5:36 am wrote:
> > >
> > > In the memory allocators used by individual processes it is possible to completely avoid
> > > memory fragmentation, e.g. by using separate memory pools for different object sizes.
> >
> > That doesn't make sense. Memory fragmentation is typically caused by differing
> > *lifetimes* of heap allocations, not by differing object sizes.
> >
>
> [snip]
>
> The fragmentation risk is the largest for the memory allocator of the operating
> system, as it will always have the longest running times between reboots.
... unless the OS was designed with memory compaction in mind.
> Due to paging, which remaps the addresses, all pages become equivalent, it does not matter which
> are allocated at a request. This reduces the memory allocation problem for the OS to the simple
> case of allocations of fixed size, when there is no danger of memory fragmentation.
No, the above paragraph is only partially true. Because: Some permutations of how the operating system has assigned pages to applications (such as: the app used mmap(MAP_ANONYMOUS) syscalls get memory from the Linux kernel) _compress_ better than other permutations, but a user-space app is _unable_ to discern the better-compressible from the less-compressible permutations.
A permutation (in this case: a permutation == the virtual memory pages allocated in response to mmap() syscalls) that compresses better in the kernel is - by definition - less fragmented in the kernel when compared to a permutation that compresses worse.
> Without paging it would be hard to guarantee that no memory would be
> lost after one year without reboots (not infrequent in servers).
The truthfulness of the above sentence solely depends on whether a person believes that memory compaction is hard to implement or believes that memory compaction is easy to implement in an operating system.
-atom
> Foo_ (foo.delete@this.nomail.com) on June 30, 2022 7:43 am wrote:
> > Adrian (a.delete@this.acm.org) on June 30, 2022 5:36 am wrote:
> > >
> > > In the memory allocators used by individual processes it is possible to completely avoid
> > > memory fragmentation, e.g. by using separate memory pools for different object sizes.
> >
> > That doesn't make sense. Memory fragmentation is typically caused by differing
> > *lifetimes* of heap allocations, not by differing object sizes.
> >
>
> [snip]
>
> The fragmentation risk is the largest for the memory allocator of the operating
> system, as it will always have the longest running times between reboots.
... unless the OS was designed with memory compaction in mind.
> Due to paging, which remaps the addresses, all pages become equivalent, it does not matter which
> are allocated at a request. This reduces the memory allocation problem for the OS to the simple
> case of allocations of fixed size, when there is no danger of memory fragmentation.
No, the above paragraph is only partially true. Because: Some permutations of how the operating system has assigned pages to applications (such as: the app used mmap(MAP_ANONYMOUS) syscalls get memory from the Linux kernel) _compress_ better than other permutations, but a user-space app is _unable_ to discern the better-compressible from the less-compressible permutations.
A permutation (in this case: a permutation == the virtual memory pages allocated in response to mmap() syscalls) that compresses better in the kernel is - by definition - less fragmented in the kernel when compared to a permutation that compresses worse.
> Without paging it would be hard to guarantee that no memory would be
> lost after one year without reboots (not infrequent in servers).
The truthfulness of the above sentence solely depends on whether a person believes that memory compaction is hard to implement or believes that memory compaction is easy to implement in an operating system.
-atom