[TUHS] If forking is bad, how about buffering?

[Bakul Shah via TUHS]

On May 18, 2024, at 7:02 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Sat, May 18, 2024 at 06:40:42PM -0700, Bakul Shah wrote:
>> On May 18, 2024, at 6:21???PM, Larry McVoy <lm at mcvoy.com> wrote:
>>> 
>>> On Sat, May 18, 2024 at 06:04:23PM -0700, Bakul Shah via TUHS wrote:
>>>> [1] This brings up a separate point: in a microkernel even a simple
>>>> thing like "foo | bar" would require a third process - a "pipe
>>>> service", to buffer up the output of foo! You may have reduced
>>>> the overhead of individual syscalls but you will have more of
>>>> cross-domain calls!
>>> 
>>> Do any micro kernels do address space to address space bcopy()?
>> 
>> mmapping the same page in two processes won't be hard but now
>> you have complicated cat (or some iolib)!
> 
> I recall asking Linus if that could be done to save TLB entries, as in
> multiple processes map a portion of their address space (at the same
> virtual location) and then they all use the same TLB entries for that
> part of their address space.  He said it couldn't be done because the
> process ID concept was hard wired into the TLB.  I don't know if TLB
> tech has evolved such that a single process could have multiple "process"
> IDs associated with it in the TLB.

Two TLB entries can point to the same physical page. Is that not good
enough? One process can give its address space a..b and the kernel
(or the memory daemon) maps a..b to other process'es a'..b'. a..b may
be associated with a file so any IO would have to be seen by both.

> I wanted it because if you could share part of your address space with
> another process, using the same TLB entries, then motivation for threads
> could go away (I've never been a threads fan but I acknowledge why
> you might need them).  I was channeling Rob's "If you think you need
> threads, your processes are too fat".

> The idea of using processes instead of threads falls down when you
> consider TLB usage.  And TLB usage, when you care about performance, is
> an issue.  I could craft you some realistic benchmarks, mirroring real
> world work loads, that would kill the idea of replacing threads with
> processes unless they shared TLB entries.  Think of a N-way threaded
> application, lots of address space used, that application uses all of the
> TLB.  Now do that with N processes and your TLB is N times less effective.
> 
> This was a conversation decades ago so maybe TLB tech now has solved this.
> I doubt it, if this was a solved problem I think every OS would say screw
> threads, just use processes and mmap().  The nice part of that model
> is you can choose what parts of your address space you want to share.
> That cuts out a HUGE swath of potential problems where another thread
> can go poke in a part of your address space that you don't want poked.

You can sort of evolve plan9's rfork to do a partial address share.
The issue with process vs thread is the context switch time. Sharing
pages doesn't change that.