By: ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com), September 23, 2021 8:37 am
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 22, 2021 11:50 am wrote:
> sr (nobody.delete@this.nowhere.com) on September 22, 2021 6:55 am wrote:
> >
> > Why would segments need different page tables? What would
> > be point of doing so instead of different processes?
>
> A segment (or whatever you want to call it: as mentioned, people don't like some of the historical connotations,
> and depending on which part of the problem you care about you might want to call it a "capability pointer")
> is much more interesting if it gives you access to other peoples address spaces.
>
> If it only partitions up an existing address space - like the x86 segments did - it
> means that segments are no good for data sharing. You can only share data if you share
> the page tables, so you don't actually get any advantage from using segments.
>
> End result: all sane operating systems ended up saying "we'll just make segments the
> maximum size, and you can just use a flat address space to access all memory".
>
> IOW, The i386 segments fundamentally didn't really add any functionality,
> they only made it more inconvenient to access memory.
>
> The only time segments are useful is if they give you added capabilities. And no, "limiting access"
> is not really an added capability from a user standpoint, despite how many computer architects
> want to do it. You need to give people something, and in that context you can then add permissions
> as a part of the parcel. Not just say "this adds no other value than limit you".
>
> So in the original 8086, people used segments - not because they liked them,
> but because segments was how you could access more than 64kB of memory.
>
> In the 80286, people used segments - again not because they liked them, but because they could (repeat after
> me) access more than 64kB of memory, but also because they could use them to handle fragmented memory (the
> 286 segments were virtual addresses, not just extra phyiscal bits) and to implement security in the OS.
>
> In the 80386 world? Nobody sane uses segments, because you can access the full address space
> without them, and you can do better security without them too. Paging is just so superior. Segments
> don't really add anything. They only make for problems, they don't make for solutions.
>
> (Yeah, there is one special case: people use segments to get access to some thread-local storage.
> So honesty in advertising - segments are still used even in the 64-bit world, but they aren't
> actually used "as segments" - they are used pretty much purely as a thread-local base address
> pointer, and the "segment" use is really just a convenient special addressing mode).
>
> But segments could be used to add something. You could use segments as a way to
> reach into another process' address space, and use them for controlled cross-process
> communication. Or on a kernel or VMM level, you could use segments as the way to access
> user memory or the virtual guest memory, or things like memory-mapped IO.
>
> IOW, you could use segments to get a bigger address space, like they did in 8086.
>
> That's not how 80386+ segments work, but other architectures have that kind of functionality (although they
> tend to be called "address spaces", not segments), where instead of having segment overrides like x86 has,
> they have address space bits in the instructions to do special loads from other memory domains.
>
> Segments could do things like that. Would it be a good idea? Probably not - history really hasn't
> been gentle to the idea of having complicated memory indirection, and segments very much are just
> an "added indirection and complication". But things like that could at least make segments part
> of the solution rather than being part of the problem, like they mostly are now.
>
> But back when segments very much were part of the solution, people pretty much universally hated
> them. They hated them on 8086, they hated them even more on 80286. And they weren't good in
> any other architecture either, it's just that at least on x86 they were successful.
>
> Linus
In other words, if I read your posts about segments correctly, you seem to be claiming that there is zero correlation between the overly simplistic type system of the C programming language (plus other languages from that era) and the downfall of segments.
I claim that if this correlation is non-zero then the downfall of segments was just a historical coincidence.
-atom
> sr (nobody.delete@this.nowhere.com) on September 22, 2021 6:55 am wrote:
> >
> > Why would segments need different page tables? What would
> > be point of doing so instead of different processes?
>
> A segment (or whatever you want to call it: as mentioned, people don't like some of the historical connotations,
> and depending on which part of the problem you care about you might want to call it a "capability pointer")
> is much more interesting if it gives you access to other peoples address spaces.
>
> If it only partitions up an existing address space - like the x86 segments did - it
> means that segments are no good for data sharing. You can only share data if you share
> the page tables, so you don't actually get any advantage from using segments.
>
> End result: all sane operating systems ended up saying "we'll just make segments the
> maximum size, and you can just use a flat address space to access all memory".
>
> IOW, The i386 segments fundamentally didn't really add any functionality,
> they only made it more inconvenient to access memory.
>
> The only time segments are useful is if they give you added capabilities. And no, "limiting access"
> is not really an added capability from a user standpoint, despite how many computer architects
> want to do it. You need to give people something, and in that context you can then add permissions
> as a part of the parcel. Not just say "this adds no other value than limit you".
>
> So in the original 8086, people used segments - not because they liked them,
> but because segments was how you could access more than 64kB of memory.
>
> In the 80286, people used segments - again not because they liked them, but because they could (repeat after
> me) access more than 64kB of memory, but also because they could use them to handle fragmented memory (the
> 286 segments were virtual addresses, not just extra phyiscal bits) and to implement security in the OS.
>
> In the 80386 world? Nobody sane uses segments, because you can access the full address space
> without them, and you can do better security without them too. Paging is just so superior. Segments
> don't really add anything. They only make for problems, they don't make for solutions.
>
> (Yeah, there is one special case: people use segments to get access to some thread-local storage.
> So honesty in advertising - segments are still used even in the 64-bit world, but they aren't
> actually used "as segments" - they are used pretty much purely as a thread-local base address
> pointer, and the "segment" use is really just a convenient special addressing mode).
>
> But segments could be used to add something. You could use segments as a way to
> reach into another process' address space, and use them for controlled cross-process
> communication. Or on a kernel or VMM level, you could use segments as the way to access
> user memory or the virtual guest memory, or things like memory-mapped IO.
>
> IOW, you could use segments to get a bigger address space, like they did in 8086.
>
> That's not how 80386+ segments work, but other architectures have that kind of functionality (although they
> tend to be called "address spaces", not segments), where instead of having segment overrides like x86 has,
> they have address space bits in the instructions to do special loads from other memory domains.
>
> Segments could do things like that. Would it be a good idea? Probably not - history really hasn't
> been gentle to the idea of having complicated memory indirection, and segments very much are just
> an "added indirection and complication". But things like that could at least make segments part
> of the solution rather than being part of the problem, like they mostly are now.
>
> But back when segments very much were part of the solution, people pretty much universally hated
> them. They hated them on 8086, they hated them even more on 80286. And they weren't good in
> any other architecture either, it's just that at least on x86 they were successful.
>
> Linus
In other words, if I read your posts about segments correctly, you seem to be claiming that there is zero correlation between the overly simplistic type system of the C programming language (plus other languages from that era) and the downfall of segments.
I claim that if this correlation is non-zero then the downfall of segments was just a historical coincidence.
-atom
Topic | Posted By | Date |
---|---|---|
POWER10 SAP SD benchmark | anon2 | 2021/09/06 02:36 PM |
POWER10 SAP SD benchmark | Daniel B | 2021/09/07 01:31 AM |
"Cores" (and SPEC) | Rayla | 2021/09/07 06:51 AM |
"Cores" (and SPEC) | anon | 2021/09/07 02:56 PM |
POWER10 SAP SD benchmark | Anon | 2021/09/07 02:24 PM |
POWER10 SAP SD benchmark | Anon | 2021/09/07 02:27 PM |
Virtually tagged L1-caches | sr | 2021/09/08 04:49 AM |
Virtually tagged L1-caches | dmcq | 2021/09/08 07:22 AM |
Virtually tagged L1-caches | sr | 2021/09/08 07:56 AM |
Virtually tagged L1-caches | Hugo Décharnes | 2021/09/08 07:58 AM |
Virtually tagged L1-caches | sr | 2021/09/08 09:09 AM |
Virtually tagged L1-caches | Hugo Décharnes | 2021/09/08 09:46 AM |
Virtually tagged L1-caches | sr | 2021/09/08 10:35 AM |
Virtually tagged L1-caches | Hugo Décharnes | 2021/09/08 11:23 AM |
Virtually tagged L1-caches | sr | 2021/09/08 11:40 AM |
Virtually tagged L1-caches | anon | 2021/09/09 02:16 AM |
Virtually tagged L1-caches | Konrad Schwarz | 2021/09/10 04:19 AM |
Virtually tagged L1-caches | Hugo Décharnes | 2021/09/10 05:59 AM |
Virtually tagged L1-caches | anon | 2021/09/14 02:17 AM |
Virtually tagged L1-caches | dmcq | 2021/09/14 08:34 AM |
Or use a PLB (NT) | Paul A. Clayton | 2021/09/14 08:45 AM |
Or use a PLB | Linus Torvalds | 2021/09/14 02:27 PM |
Or use a PLB | anon | 2021/09/14 11:15 PM |
Or use a PLB | Michael S | 2021/09/15 02:21 AM |
Or use a PLB | dmcq | 2021/09/15 02:42 PM |
Or use a PLB | Konrad Schwarz | 2021/09/16 03:24 AM |
Or use a PLB | Michael S | 2021/09/16 09:13 AM |
Or use a PLB | --- | 2021/09/16 12:02 PM |
PLB reference | Paul A. Clayton | 2021/09/18 01:35 PM |
PLB reference | Michael S | 2021/09/18 03:14 PM |
Demand paging/translation orthogonal | Paul A. Clayton | 2021/09/19 06:33 AM |
Demand paging/translation orthogonal | Michael S | 2021/09/19 08:10 AM |
PLB reference | Carson | 2021/09/20 09:19 PM |
PLB reference | sr | 2021/09/20 05:02 AM |
PLB reference | Michael S | 2021/09/20 06:03 AM |
PLB reference | Linus Torvalds | 2021/09/20 11:10 AM |
Or use a PLB | sr | 2021/09/20 03:32 AM |
Or use a PLB | sr | 2021/09/21 08:36 AM |
Or use a PLB | Linus Torvalds | 2021/09/21 09:04 AM |
Or use a PLB | sr | 2021/09/21 09:48 AM |
Or use a PLB | Linus Torvalds | 2021/09/21 12:55 PM |
Or use a PLB | sr | 2021/09/22 05:55 AM |
Or use a PLB | rwessel | 2021/09/22 06:09 AM |
Or use a PLB | Linus Torvalds | 2021/09/22 10:50 AM |
Or use a PLB | sr | 2021/09/22 12:00 PM |
Or use a PLB | dmcq | 2021/09/22 03:07 PM |
Or use a PLB | Etienne Lorrain | 2021/09/23 07:50 AM |
Or use a PLB | anon2 | 2021/09/22 03:09 PM |
Or use a PLB | dmcq | 2021/09/23 01:35 AM |
Or use a PLB | ⚛ | 2021/09/23 08:37 AM |
Or use a PLB | Linus Torvalds | 2021/09/23 11:01 AM |
Or use a PLB | gpd | 2021/09/24 02:59 AM |
Or use a PLB | Linus Torvalds | 2021/09/24 09:45 AM |
Or use a PLB | dmcq | 2021/09/24 11:43 AM |
Or use a PLB | sr | 2021/09/25 09:19 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 09:44 AM |
Or use a PLB | sr | 2021/09/25 10:11 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 10:31 AM |
Or use a PLB | sr | 2021/09/25 10:52 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 11:05 AM |
Or use a PLB | sr | 2021/09/25 11:23 AM |
Or use a PLB | rwessel | 2021/09/25 02:29 PM |
Or use a PLB | sr | 2021/09/30 11:22 PM |
Or use a PLB | rwessel | 2021/10/01 05:19 AM |
Or use a PLB | David Hess | 2021/10/01 09:35 AM |
Or use a PLB | rwessel | 2021/10/02 03:47 AM |
Or use a PLB | sr | 2021/10/02 10:16 AM |
Or use a PLB | rwessel | 2021/10/02 10:53 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 10:57 AM |
Or use a PLB | sr | 2021/09/25 11:07 AM |
Or use a PLB | Linus Torvalds | 2021/09/25 11:21 AM |
Or use a PLB | sr | 2021/09/25 11:40 AM |
Or use a PLB | nksingh | 2021/09/27 08:07 AM |
Or use a PLB | ⚛ | 2021/09/27 08:02 AM |
Or use a PLB | Linus Torvalds | 2021/09/27 09:20 AM |
Or use a PLB | Linus Torvalds | 2021/09/27 11:58 AM |
Or use a PLB | dmcq | 2021/09/28 09:59 AM |
Or use a PLB | sr | 2021/09/25 09:34 AM |
Or use a PLB | rwessel | 2021/09/25 02:44 PM |
Or use a PLB | sr | 2021/10/01 12:04 AM |
Or use a PLB | rwessel | 2021/10/01 05:33 AM |
I386 segmentation highlights | sr | 2021/10/04 06:53 AM |
I386 segmentation highlights | Adrian | 2021/10/04 08:53 AM |
I386 segmentation highlights | sr | 2021/10/04 09:19 AM |
I386 segmentation highlights | rwessel | 2021/10/04 03:57 PM |
I386 segmentation highlights | sr | 2021/10/05 10:16 AM |
I386 segmentation highlights | Michael S | 2021/10/05 11:27 AM |
I386 segmentation highlights | rwessel | 2021/10/05 03:20 PM |
Or use a PLB | JohnG | 2021/09/25 09:18 PM |
Or use a PLB | ⚛ | 2021/09/27 06:37 AM |
Or use a PLB | Heikki Kultala | 2021/09/28 02:53 AM |
Or use a PLB | rwessel | 2021/09/28 06:29 AM |
Or use a PLB | David Hess | 2021/09/23 05:00 PM |
Or use a PLB | Adrian | 2021/09/24 12:21 AM |
Or use a PLB | dmcq | 2021/09/25 11:41 AM |
Or use a PLB | blaine | 2021/09/26 10:19 PM |
Or use a PLB | David Hess | 2021/09/27 10:35 AM |
Or use a PLB | blaine | 2021/09/27 04:19 PM |
Or use a PLB | Adrian | 2021/09/27 09:40 PM |
Or use a PLB | Adrian | 2021/09/27 09:59 PM |
Or use a PLB | dmcq | 2021/09/28 06:45 AM |
Or use a PLB | rwessel | 2021/09/28 06:45 AM |
Or use a PLB | David Hess | 2021/09/28 11:50 AM |
Or use a PLB | Etienne Lorrain | 2021/09/30 12:25 AM |
Or use a PLB | David Hess | 2021/10/01 09:40 AM |
MMU privileges | sr | 2021/09/21 10:07 AM |
MMU privileges | Linus Torvalds | 2021/09/21 12:49 PM |
Virtually tagged L1-caches | Konrad Schwarz | 2021/09/16 03:18 AM |
Virtually tagged L1-caches | Carson | 2021/09/16 12:12 PM |
Virtually tagged L1-caches | anon2 | 2021/09/16 04:16 PM |
Virtually tagged L1-caches | rwessel | 2021/09/16 05:29 PM |
Virtually tagged L1-caches | sr | 2021/09/20 03:20 AM |
Virtually tagged L1-caches | --- | 2021/09/08 01:28 PM |
Virtually tagged L1-caches | anonymou5 | 2021/09/08 07:28 PM |
Virtually tagged L1-caches | anonymou5 | 2021/09/08 07:34 PM |
Virtually tagged L1-caches | --- | 2021/09/09 09:14 AM |
Virtually tagged L1-caches | anonymou5 | 2021/09/09 09:44 PM |
Multi-threading? | David Kanter | 2021/09/09 08:32 PM |
Multi-threading? | --- | 2021/09/10 08:19 AM |
Virtually tagged L1-caches | sr | 2021/09/11 12:19 AM |
Virtually tagged L1-caches | sr | 2021/09/11 12:36 AM |
Virtually tagged L1-caches | --- | 2021/09/11 08:53 AM |
Virtually tagged L1-caches | sr | 2021/09/11 11:43 PM |
Virtually tagged L1-caches | Linus Torvalds | 2021/09/12 10:10 AM |
Virtually tagged L1-caches | sr | 2021/09/12 10:57 AM |
Virtually tagged L1-caches | dmcq | 2021/09/13 07:31 AM |
Virtually tagged L1-caches | sr | 2021/09/20 03:11 AM |
Virtually tagged L1-caches | sr | 2021/09/11 01:49 AM |
Virtually tagged L1-caches | Linus Torvalds | 2021/09/08 11:34 AM |
Virtually tagged L1-caches | dmcq | 2021/09/09 01:46 AM |
Virtually tagged L1-caches | dmcq | 2021/09/09 01:58 AM |
Virtually tagged L1-caches | sr | 2021/09/11 12:29 AM |
Virtually tagged L1-caches | dmcq | 2021/09/11 07:59 AM |
Virtually tagged L1-caches | sr | 2021/09/11 11:57 PM |
Virtually tagged L1-caches | dmcq | 2021/09/12 07:44 AM |
Virtually tagged L1-caches | sr | 2021/09/12 08:48 AM |
Virtually tagged L1-caches | dmcq | 2021/09/12 12:22 PM |
Virtually tagged L1-caches | sr | 2021/09/20 03:40 AM |
Where do you see this information? (NT) | anon2 | 2021/09/09 01:45 AM |
Where do you see this information? | sr | 2021/09/11 12:40 AM |
Where do you see this information? | anon2 | 2021/09/11 12:53 AM |
Where do you see this information? | sr | 2021/09/11 01:08 AM |
Thank you (NT) | anon2 | 2021/09/11 03:31 PM |