l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPC etc. (was: Future Direction of GNU Hurd?)


From: William ML Leslie
Subject: Re: IPC etc. (was: Future Direction of GNU Hurd?)
Date: Thu, 25 Mar 2021 09:12:29 +1100

Reposting to l4-hurd as I presume that was your intention Shap, though
I always love to get personal mail from you!  It has been too long,
and I'm sorry about that.

On Thu, 25 Mar 2021 at 00:35, Jonathan S. Shapiro
<jonathan.s.shapiro@gmail.com> wrote:
>
> On Wed, Mar 24, 2021 at 12:56 AM William ML Leslie 
> <william.leslie.ttg@gmail.com> wrote:
>>
>> One is to make string transfer in Coyotos reliable.  You say "require
>> these pages to be resident before sending" and then the message send
>> will delay until the string transfer will complete without paging.
>
>
> Translating this into English, this converts to "set a small upper bound on 
> the message size."
>
> In real applications, large messages can be very important. In microkernels, 
> it is not unusual for a large message payload to exceed the total available 
> kernel virtual memory. KeyKOS and EROS behaved as William proposes. It was a 
> huge pain in the ass that led to significantly increased message traffic. 
> Williams proposal also means that the duration of a kernel transaction cannot 
> be bounded. Solving this was one of the big advances in Coyotos.
>

Coyotos has a 64kb limit on the size of indirect strings, and these
get truncated if any of the pages are not prepared.  This gets much
more irritating in the async case, so being able to asynchronously say
"have these pages loaded, and then send this message" becomes
essential.

>> Particularly important with async IPC, where loads of messages may be
>> touching all sorts of pages.
>
>
> I wonder if you are mis-defining reliable. The question isn't whether the 
> message goes in one piece. The question is whether the message goes. Coyotos 
> solves this with a restartable string transfer approach.
>

I'll double check the source, it's possible I've misunderstood the new
string transfer mechanism.  I've been busy with ccs-xenv (now building
with gcc 10, binutils 2.35, etc) and updating the host tools to modern
C++ and haven't been so deep in the kernel itself yet.

>>
>> Another is a GC heap walk.  Most operating systems get very confused
>> by GC and get to the point where they make no progress, because it
>> sees that pages were recently touched and so decides shouldn't be
>> paged out.  Having the GC declare where its fingers are and where they
>> are headed as the requirement for residency gives the power back to
>> the process.
>
>
> Modern GCs use things like madvise() to alleviate this.
>

For which we have no interface in Coyotos, yet.

I haven't wanted to hassle you with this stuff while I am doing the
boring work of e.g. replacing `shared_ptr` with `boost::shared_ptr`,
but I'm definitely unsure on how best to implement the remaining
functionality that Coyotos will need.  You've told me a lot about how
to build a secure kernel, but I'm still very spotty on how to build
the system above it.

>>
>> > > An aside: I absolutely want to have optional orthogonal persistence
>> > > per-application.  Imagine having emacs up and ready to go the moment
>> > > you log into your machine.  Yes please.
>> >
>> > How would that work per-application? Don't we have to restore the
>> > application's environment (including capabilities) -- meaning it has to
>> > be more or less system-wide?...
>>
>> CapROS (and presumably EROS, too) have a set of non-persistent
>> applications that most of the persistent processes depend on.  It
>> feels a little like how GNU shepherd and systemd pre-open sockets and
>> pretend the application is already available.
>
>
> These were for drivers only. They never worked to my satisfaction.
>

I'm not even sure what you settled on here.  FWIR we went back and
forth on orthogonal persistence a bunch of times.

-- 
William Leslie

Q: What is your boss's password?
A: "Authentication", clearly

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]