V.3 + top
Paul Fox
fox at marlow.uucp
Mon Oct 31 22:54:38 AEST 1988
In article <10770006 at hpcupt1.HP.COM> vandys at hpcupt1.HP.COM (Andrew Valencia(Seattle)) writes:
> ... Originally, being swapped out was virtually
>equated with moving the U area out of memory. These days, a number of other
>things rank right up there with the U area. Page tables, for instance.
>They tend to use even more space than U areas. The U area's relationship
>to the actions of the VM system has become less dominating than it once
>was, as all manner of stuff gets heaped into the memory management picture.
>
Following on from my original posting, heres a status update.
Having got top to run I find that my system is 93% busy in the
kernel, EVEN WHEN ITS NOT DOING ANYTHING. After a number of weeks
of fretting and watching the appalling system response, I finally
resorted to removing DOS-MERGE from my kernel. And what do you know ?
I get normal system response times. Jeeze...
Anyway system response is still not too hot, but now I've modified top
to tell me what events sleeping processes are waiting on -- and I can
see that disk intensive processes are (quite rightly) waiting on
disk buffers, etc....
What I wanted to be able to do was print out how much of a process
was resident in memory. I've worked out some of the details --
scan the processes page directory and page table entries tosee which
pages are marked as present, but this approach would appear to be
potentially very CPU intensive - a process has 1024 page directory
tables * 1024 pages within each table. Although most of the address
space is sparse it would appear that I still need to scan the entirety
of these tables.
Does anyone know of a way of easily determining how much of a process
is resident, or of some other useful kernel quantity that can give
some idea of system response ?
=====================
// o All opinions are my own.
(O) ( ) The powers that be ...
/ \_____( )
o \ |
/\____\__/ Tel: +44 628 891313 x. 212
_/_/ _/_/ UUCP: fox at marlow.uucp
More information about the Comp.unix.microport
mailing list