Experimental OS development using D

Harry Vennik htvennik at zonnet.nl
Thu Jan 4 14:45:53 PST 2007


>Harry Vennik wrote:
>> BCS wrote:
>>
>>>Put the security in stetting up the shared buffers and that should do
>>>it I'd think.
>>>Read access lets you map it in in a read only page, read/write... etc.
>>>
>>>One thought I had on this issue is that it allows much of the IO to
>>>run without system calls/context switches if the stream access and
>>>whatnot is all run as part of the standard system lib. Plus, while you
>>>can mess with your stream meta data, it only hoses you.
>>
>>
>> I have been thinking that way too, but it is difficult to see how much it really
>> prevents context switches. It may just obscure them by having them occur only in
>> response to certain events (which may occur regularly), instead of having the
>> predictable context switch for every read/write/whatever you do.
>> Memory-mapping the file will prevent this, but is costly for bigger files, so this
>> needs some thought. Anyway, if a way is found to have a reliable shared-buffer
>> implementation that will not compensate its lower number of context switches by
>> having more of another unwanted side-effect (e.g. excessive memory usage), than
>> that would certainly be the way to go.
>>
>> Harry
>
> The appropriate snide response here is "memory is cheap". But I've never
> bought into that one. If the IO system allowed arbitrary mapping of
> memory pages to disk blocks:
>
> sysCallMapPage2Block(int fd, size_t block, void* page, uint count = 1);
>
> this might not be fairly fast as far as the OS side goes.
>
> if(fd.good && fd.size >= block &&
>  user.pageCount + count < suer.pageLimit)
>  MapPage();
>
> The other side would be totally up to the stdlib ("not your problem" :-)
>
> This would have some other cool effects like use this under malloc
> (fd == -1 indicates blank pages)

No, this won't fit in the concept. I think of it like this (Only mentioning the relevant steps.):
- A process does an IPC call to the filesystem service to map some data from a file into memory.
- The fs service reads the data from disk and puts it into newly allocated memory page(s).
- The fs service announces to the kernel which pages should be mapped into the virtual address space
of the calling process, and returns the pointer.
- The kernel maps the shareable memory into the virtual address space of the calling process, and
translates the returned pointer to reflect the correct address in the calling process' address space.

I think that's the best we can do. It is secure (at least at first sight), and it should save quite a lot of
syscalls, except when reading/writing a large file randomly.

Harry



More information about the Digitalmars-d-announce mailing list