[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipc security
From: |
Marcus Brinkmann |
Subject: |
Re: ipc security |
Date: |
Thu, 21 Oct 2004 18:13:40 +0200 |
User-agent: |
Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Wed, 20 Oct 2004 22:54:47 +0200,
Ludovic Courtès <address@hidden> wrote:
> Does this mean that the number of tasks that could possibly run in the
> system is bound by the amount of physical memory available over the
> amount of physical "unmappable" memory granted to each task?
>
> Hope this makes sense.
This was true until yesterday ;) I have proposed to Neal a smallish
modification to physmem, that allows you to use physmem as a last
resort pager for the last pager in each task. This can be used to
allow physmem to temporarily unmap the pager's working set for
reorganization of memory (make space for superpages, etc).
Theoretically, you could then also let physmem swap out that memory,
but that's not something we want to do. So, the limitation still
applies (at least practically).
BTW, the original motivation for this change was that we want to be
able to deny task-to-task memory mappings, and map everything through
physmem, and that was not possible with the current startup protocol.
However, if we use this, we can also let physmem map the startup code
(instead mapping it through the task starting the new task).
We are not yet sure if we really go for this design, but the benefit
of being able to never hard-wire such memory is potentially huge, both
in memory performance and also in design (because we did not have a
design how to do wiring anyway yet, so any simplification of that
issue is welcome).
In any case, we are talking about kilobytes here, not hundred of
kilobytes. So it should by far not what limits you. Johan gave the
reason.
Thanks,
Marcus
- RE: ipc security, Volkmar Uhlig, 2004/10/08
- Re: ipc security, Bas Wijnen, 2004/10/14
- Re: ipc security, Marcus Brinkmann, 2004/10/19
- Re: ipc security, Bas Wijnen, 2004/10/21
- Re: ipc security, Marcus Brinkmann, 2004/10/21
- Re: ipc security, Bas Wijnen, 2004/10/22
- Re: ipc security, Marcus Brinkmann, 2004/10/22
- Re: ipc security, Bas Wijnen, 2004/10/22
- Re: ipc security, Marcus Brinkmann, 2004/10/22