hanche@imf.unit.no (Harald Hanche-Olsen) (12/17/90)
In article <4e997ec6.1bc5b@pisa.ifs.umich.edu> rees@pisa.ifs.umich.edu (Jim Rees) writes:
Domain/OS has a pair of processes, the purifiers (pids 3 & 4), that
progressively write dirty objects to disk. I think they only write pages
from unlocked objects. So the combination of the purifiers and sync should
be sufficient.
This is interesting. I have always wondered what those first ten
processes are there for:
USER PID SZ RSS TTY STAT TIME COMMAND
root 1 6144 808 ? S < 0:05 /etc/init
root 2 0 0 ? R 1366:11 null
root 3 0 0 ? S 0:00 purifier
root 4 0 0 ? S 0:00 purifier
root 5 0 0 ? S 3:39 unwired_dxm
root 6 0 0 ? S 0:00 pinger
root 7 0 0 ? S 4:41 netreceive
root 8 0 0 ? S 0:08 netpaging
root 9 0 0 ? S 0:05 wired_dxm
root 10 0 0 ? S 0:21 netrequest
I understand #1 and #2, of course (init even has a man page), and now
Jim has explained #3 and #4. Could anybody explain the remainder?
No, I don't think I need to know. Just being curious, that's all.
- Harald Hanche-Olsen <hanche@imf.unit.no>
Division of Mathematical Sciences
The Norwegian Institute of Technology
N-7034 Trondheim, NORWAYmroussel@alchemy.chem.utoronto.ca (Marc Roussel) (12/18/90)
In article <HANCHE.90Dec17115202@hufsa.imf.unit.no> hanche@imf.unit.no (Harald Hanche-Olsen) writes: >In article <4e997ec6.1bc5b@pisa.ifs.umich.edu> rees@pisa.ifs.umich.edu (Jim >Rees) writes: > > Domain/OS has a pair of processes, the purifiers (pids 3 & 4), that > progressively write dirty objects to disk. I think they only write pages > from unlocked objects. So the combination of the purifiers and sync should > be sufficient. > >This is interesting. I have always wondered what those first ten >processes are there for: [listing of those 10 first processes deleted] >I understand #1 and #2, of course (init even has a man page), and now >Jim has explained #3 and #4. Could anybody explain the remainder? >No, I don't think I need to know. Just being curious, that's all. I'm curious too. Why two purifier processes? They both have the same name; are they invoked differently and thus carry out different functions? Marc R. Roussel mroussel@alchemy.chem.utoronto.ca
ced@apollo.HP.COM (Carl Davidson) (12/18/90)
From article <HANCHE.90Dec17115202@hufsa.imf.unit.no>, by hanche@imf.unit.no (Harald Hanche-Olsen): > > This is interesting. I have always wondered what those first ten > processes are there for: > > USER PID SZ RSS TTY STAT TIME COMMAND > root 1 6144 808 ? S < 0:05 /etc/init > root 2 0 0 ? R 1366:11 null > root 3 0 0 ? S 0:00 purifier > root 4 0 0 ? S 0:00 purifier > root 5 0 0 ? S 3:39 unwired_dxm > root 6 0 0 ? S 0:00 pinger > root 7 0 0 ? S 4:41 netreceive > root 8 0 0 ? S 0:08 netpaging > root 9 0 0 ? S 0:05 wired_dxm > root 10 0 0 ? S 0:21 netrequest > > I understand #1 and #2, of course (init even has a man page), and now > Jim has explained #3 and #4. Could anybody explain the remainder? > No, I don't think I need to know. Just being curious, that's all. > > - Harald Hanche-Olsen <hanche@imf.unit.no> > Division of Mathematical Sciences > The Norwegian Institute of Technology > N-7034 Trondheim, NORWAY Well, let's see... > USER PID SZ RSS TTY STAT TIME COMMAND > root 5 0 0 ? S 3:39 unwired_dxm > root 9 0 0 ? S 0:05 wired_dxm From somebody's notes (not mine): The DXM routines allow procedures to be called from a "safe" context. The problem they address is that it is often not possible to call certain procedures from interrupt level. For example, the when the terminal driver receives a quit character, it would like to be able to call "proc2_$trace_fault", but it can't since the driver is running at interrupt time and "proc2_$trace_fault" is not wired. Besides not being wired, it may be unreasonable to call some procedures from interrupt level because those procedures may take a long time to run. and There are two processes that support DXM: the wired and unwired DXM. When you defer a procedure, you must specify whether the procedure will cause no page faults or not. The wired DXM runs all deferred procedures that will not cause page faults. The unwired DXM runs all deferred procedures that may cause page faults. > root 6 0 0 ? S 0:00 pinger A kernel server that helps the network subsystem determine whether a target node is on the net or not. If a remote node sends a Domain ping packet to your node, this process responds to it. > root 7 0 0 ? S 4:41 netreceive The Domain/OS equivalent of a Mach netisr thread. For each network adapter there is a Net Receive Server (the Aegis {gack!} name) which handles the demultiplexing of incoming packets to the various clients. > root 8 0 0 ? S 0:08 netpaging This process answers paging requests from remote nodes. You can run up to three of them simultaneously by invoking the command netsvc -s {numservers}. If you have a lot of remote clients, it will help. > root 10 0 0 ? S 0:21 netrequest A friend of the netpaging server. This one handles lcnode, rip, and file requests from remote nodes. In another news note, someone asked why there are two page purifiers. There are two purifiers because one gives preference to "local" pages and the other gives preference to "remote" pages, where "local" and "remote" are determined by whether the backing store for the page resides on this node or some other node in the network. Flushing a page to a remote node can sometimes take a long time. The purifier sleeps while waiting for the response. If there were only one purifier, local pages might not get flushed as often as they should, hence the two processes. We now return you to your regularly scheduled newsgroup. Carl Davidson (508) 256-6600 x4361 | The Apollo Systems Divison of | It doesn't TAKE all kinds, The Hewlett-Packard Company | there just ARE all kinds. DOMAIN: ced@apollo.HP.COM |