Re: BSD VM architecture...

From: Steve H (netspam_at_shic.co.uk)
Date: 06/07/03 

Date: 7 Jun 2003 03:21:22 -0700

First, before you consider me ungrateful, thanks for being a sounding
board... Since I started this Usenet thread, I've realised several
relevant things about this problem, which will certainly prove helpful
with whatever solution I end up selecting. The most important
"discovery" is that this programmatic VM space switch would need to be
done by the Kernel Scheduler, not by a call from user space as I'd
originally envisioned. I will need to ensure that each execution
context has a fixed 4Gb address space.

Conversely, unless the answer is "it's never been tried" - then I
don't think I've resolved my original "research" goal.

phil-news-nospam@ipal.net wrote in message news:<bbqasb41qqd@enews3.newsguy.com>...
> You've talked about switching VM space already, anyway. So we do
> make some assumptions. Keep in mind that you are NOT describing
> this to us in terms of the actual problem needing a solution, but
> rather, are giving us bits and pieces of a problematic solution
> needing a fix (for which there may not be any). If you could tell
> us exactly the application, maybe we can tell you what to do. Or
> maybe we'd need to be paid a big consulting fee depending on the
> size of this whole project.

Fair points... unfortunately there's no finance available for
consultancy positions:-( I find this stuff interesting, and hoped to
find like-minded people who may have tackled the same issue
previously. I intentionally avoided a full description of the project
- that would be one hell of a long Usenet post - and I can almost
guarantee that discussions would veer wildly from that which interests
me at the moment - namely a halfway house between threads and
processes.

> If you do want to switch the address space around as execution
> switches threads, what you have is effectively the process model
> and all its associated overheads. If you're going to do such
> switching with threads, how are the threads going to communicate?
> Is there going to be _some_ memory still shared? If so, then it's
> just the same as processes with some address space mapped to a
> shared object and sharing that way.
> When the context switches, and if you also switch address spaces,
> you have the process model.

(I may have mentioned the following in a previous post, but it hasn't
appeared 24 hours later... I wonder why Google groups is so slow...)

Your comments are absolutely correct when considering a stock
Unix-like kernel. We understand the difference between threads and
processes:

        1. Threads share a the single Process-wide 32-bit VM space
           Inter-context synchronisation/parameter sharing is very fast.
           New shared memory can be allocated by any thread. (Minor issue)
        2. Processes have independent 32 bit VM spaces
           Inter-context synchronisation/parameter sharing is slower.
           Shared memory must be allocated prior to fork. (Minor issue)

Have people experimented with Thresses or Preads? It seems such an
obvious idea, I can't believe that no-one before me has thought about
this. I want something which works like threads for 3Gb of my address
space and like Processes for the remaining 1Gb (or preferably allow
this split to be controlled programmatically. I'd hope to benefit
from fast synchronisation (by virtue of the shared address space) and
the ability to independently maintain large file mappings in each
context using the thread-local address space.

> How much address space, in megabytes, are you thinking your processes
> need to retain as shared in order to avoid the IPC overhead? Well,
> whatever that is, I'll say mmap() a shared object that size into
> separate processes and use the process model.

Sure, I could do that - and even have an experimental prototype. The
MM library by Ralf Engelschall (great library, cheesy website) makes
this sharing pretty straightforward... but this doesn't address the
difference in performance between synchronising threads and
synchronising processes.

> As far as I can tell, you're avoiding processes only because threads
> was your first exposure to multitasking programs. And yet, you have
> re-invented processes.

Not quite (historically speaking, it was the other way round:)

I'd like to avoid processes in favour of threads in order to minimise
the performance impact of synchronisations between contexts. I'd like
to avoid threads in favour of processes because I want each context to
independently mmap() data blocks... while retaining shared control
structures. Neither threads nor processes require customised kernels,
yet each has disadvantages. I'm trying to investigate a third way.
How can I modify a kernel to allow a different model for multiple
execution contexts? Has this been done before? Was it successful - or
why did it fail? Can anyone point me at similar projects?

Steve

Relevant Pages
Loading