Re: memory managment in servers?

Hi,

Basile STARYNKEVITCH wrote:
>
> 0. How does the swapping actually work. I believe i begin to
> understand the filesystem protocol designed for that (ie FS_ABSREAD
> FS_ABSWRITE and FS_FID) but i don't know how it is used?

Erm, well at the moment the swapper doesn't work properly :-( (the
principal's right though). The FS_ABSXXXX messages are used simply to
acheive the same effect as FS_SEEK followed by either FS_READ or FS_WRITE.
In fact none of the filesystem servers can be used as a swap device as swap
devices must work as DMA servers - so far only wd, fd and cam can do this.
FS_FID is used for handling file mapping and isn't used for swapping.

FWIW FS_ABSXXXXX aren't just used by the swapper code, as they're also used
by the libc code that handles misaligned I/O read()/write() requests (see
libc/fdl.c)

> 1. Who is deciding the swapping (ie paging) policy? In other words,
> who decide of the paging strategy (FIFO, best fit, etc)? Is it the
> kernel or a dedicated swap server? (I think that Andys recommended me
> to not use it currently since there are some bugs in the swap code).

The kernel makes the decisions, swapd just provides the mechanism for moving
the pages.

> 2. Assuming a filesystem server is booted (perhaps some day a foolish
> guy would even install my ext2fs as a boot server ie in
> /boot/boot.lst) i believe it can't swap, so it works (hence malloc) in
> physical memory, not in virtual memory. Can somebody confirm or
> explain if i'm wrong.

Well it still uses VM, it's just that all of it's memory is always present
:-) Essentially though (as I understand it) any server loaded at the
initial boot (not through init) will never swap.

> 3. I wish and am prepared to have some kind of memory-low
> message. Does such a beast exists? I mean that my ext2fs allocate
> dynamically (block and inode) cache and free them on a age basis (ie
> it free the oldest unused block and inode in server memory -not on
> disk). So it is very easy to me to handle a PLEASE_GIVE_BACK(N Kbytes)
> message asking to free at least N kilobytes - i could also handle a
> simpler MEMORY_LOW message asking to free as much memory as i can.

This sounds a good idea. I'd been thinking about how to do this a while
back and this seems much saner than my original thoughts :-) I assume that
you're proposing this be a message, eg FS_MEMORY, so that we can ask any
server that want's too listen for some more memory. I guess the question
must be when and how such a message would be sent? I also wonder about how
we'd decide which server to ask for memory - I don't know what the answer is
though.

> 4. What exactly are VSTa events and notifies? I guess they generalize
> posix signals in a message like fashion but i don't grap an exact
> picture of them (eg can they be blocked, delayed, are they reliable,
> sendable by anyone).

Basically events are like POSIX signals - hence the libc emulation code.
"kill" is a special one however whose behaviour is hard coded in the kernel.
Basically only a process with an ID that dominates the default ID on the
process being sent the event should be able to send. This doesn't work
properly on standard 1.3.2, but there again the namer permissions bug stops
any non group sys.sys user from loging in and so this isn't obvious. One of
the sets of patches I recently sent into Andy fix the ID handling and thus
this bit of code should work properly on the next release.

If I'm correct, we only check for events in a couple of places as we leave
kernel code, and we only look for (and therefore process) events for the
current process (we may have only just become the current process of course
if we switched whilst in the kernel).

                        Regards,
                        Dave
Received on Wed Nov 23 06:40:36 1994