OSDev.org

A few weeks ago, i was sharing the 'ports' addition of clicker. Among key concepts, 'messages' were small and of fixed size (4 dwords) and threads could act as 'container' for messages that are yet to be sent or that are yet to be received.

Now, i'm just starting to add support for zero-copy "jumbo messages" (which can grow up to 4MB). The key idea is to have (at the receiver) a memory structure that can temporarily map received jumbos while they're processed. In the case of a Jumbo Message, clicker will transmit the frame number for the holding page table plus a "exported address" which is made of:

- how many pages are exported (10 bits)
- what's the index of the first exported page in the table (10 bits)
- what's the offset of the exported data in that first page (12 bits)

Table Frame number is part of the 'message code' and we expect that one jumbo only use one table (which means you can have as many 'exported address' as you want in the message.

The receiver uses a hash-table-driven cache of page tables and another hash-table for pages, which means it can avoid re-mapping a page that has already been mapped (hum. it should. this is still under progress ...)

I see some docs on your side is in french. You speak french?

ah - copyless message passing - that would speed up quite some things

passing around a shared memory entity which the receiver can map in is no option, is it? well - the overhead of shared mem management would kill the speed benefit *hmmmmm* gonna see.

I gonna check back have to look at this at home. Work to do.

beyond infinity wrote: passing around a shared memory entity which the receiver can map in is no option, is it?

Actually that's more or less what's happening, except i don't require the _whole_ entity to be shared, only what's needed.

The situation is that you will have several process (usually servers) contributing to the Kernel Dynamic Storage. The video server could (for instance) keep a list of all available video modes while the network server keeps the ARP cache. I'd like an application (that has enough credentials) to be able to access those informations, but without having to map the _whole_ exported information at the application (only what's requested). Moreover, the application has control over how much virtual memory it dedicates to mapping jumbo messages.


And indeed, i'm natively french-speaking belgian dude (i mean, before i got relocated in a galaxy, far, far away).

And indeed, i'm natively french-speaking belgian dude (i mean, before i got relocated in a galaxy, far, far away).

I'm a nativaly french-speaking person too, though from the other side of the world

quebec, eh?

Ici en autriche il fait beaucoup de nuages. Comme est-il, le temps en Quebec?

beaucoup de nuages

environ 5-6 degres C

Excuse me if I'm dense, but that does imply that a Jumbo Message must not include absolute pointers, as it cannot be guaranteed that the receiver maps the page(s) at the same virtual address than the sender - right?

indeed. Jumbo messages are meant to ease the transmission of large text, lists (if serialized properly) and things alike. But they remain _messages_ which means they cannot contain flat pointers.

@BI: you should have said "il y a beaucoup de nuages" (very cloudy) and "Quel temps fait-il au Quebec" (How's the weather like, in Quebec) B)

Solar wrote: Excuse me if I'm dense, but that does imply that a Jumbo Message must not include absolute pointers, as it cannot be guaranteed that the receiver maps the page(s) at the same virtual address than the sender - right?

actually, i had a solution to pass arbitrary structures, provided that they come from a single "exporting" area:

1. the client side traverses the structure, identifying all the pointers (okay, that means you have to know the actual structure. This is the job of some auto-generated code of some sort based on the structure itself).

2. from that traversal, one builds a "relocation list" that indicates the 'exportable address' of every component in the structure and the list of pointers manipulation that is required for that component.

3. the kernel simply passes the 'relocation list' as a jumbo message.

Then i'm not yet decided of whether i'll have the structure re-created locally or use accessors to lazily import data and re-locate pointers on the fly. That probably depends on what you want to do with the imported structure.

somehow the title makes me amazed... probably due to a little headache

you have very very large messages in a kernel designed to be very small and fast?

@pype: Merci pour la correction. Il me faut d'exercicer le francais plus.

@candy: you are sure you don't want a Aspirin?

Candy wrote: you have very very large messages in a kernel designed to be very small and fast?

Well, should the fact the kernel is small and fast imply that process running on top of that kernel cannot swap large amount of data ? Be it simply file names or URLs, those are usually too large for going through the 'usual' 4 or 8 dwords messages ...

Depending on how you use your messaging system, you could end up with messages containing GUI bitmaps, audio samples, or 3D textures...