Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 25, 2021 11:57 am wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 25, 2021 11:31 am wrote:
> > sr (nobody.delete@this.nowhere.com) on September 25, 2021 11:11 am wrote:
> > >
> > > Am I understand 386 segmentation wrongly? Process have all rights and you
> > > could segment it pretty much without limits to any wanted slices, dynamically.
> > > Page size isn't limiting factor, segments can go smaller than pages.
> >
> > You are wrong in some details, but not in the big picture (*).
>
> That '(*)' was because I was going to point out that i386 segments actually end up having
> page granularity once they hit a certain size, but then I forgot to add the footnote.
>
> So the page granularity ends up being an issue even with segments, but you hit that
> only by the time you do 1MB+ allocations, and at that point your offsets wouldn't
> be checked at the exact byte boundary of your allocation, but at 4kB boundaries.
>
> It is fine in practice, but it does mean that if you use segments for
> buffer overflow protection, you will have some granularity issues.
>
> That's fine. The ARM pointer coloring I've mentioned has something like a 32-byte allocation granularity
> too, I forget. Some granularity is almost inevitable just to avoid excessive metadata overhead.
>


You really complain about those limitations? Those are for hardware, if they want to use more bits for boundaries they need to waste more space for addressing limiting performance and backwards-compatibility.

And about memory allocation - for very small allocations fine granularity is acceptable but for larger ones isn't it wise to allocate to page limits even if hardware allows finer allocation?