On Tue, 25 Feb 1997, Ale Terlevich wrote:

>    I've recently nocied that update seems to be taking up too much CPU 
> time according to top.
> 
> I'm running a kernel compiled today, with the vm_update.c patched
> as announced in current-users today, and a SA110 CPU
> 
>   It varies from 6% when it's 'sleeping' for its 30 seconds to upto 30 or 
> even 50% when it 'wakes up'. When it does wake up, the whole machine 
> freezes for about a second (At least typing into this xterm does) and 
> when it unfreezes, I often get the last key pressed repeated many times 
> over. It also doesn't seem to register keypresses while frozen.
> 
>   Oh, another thing. I'm not actually doing anything to the filesystem at 
> the mo, so syncing the disks isn't writing anything to them.
> 
>   I don't think this happened with kernels compiled  ~2 weeks ago.  
> 
> Has anyone else experienced this with the latest source?  Can anyone shed 
> light on this?

Yep this is due to a recent fix to the sync syscall.

A recent change added a call to vnode_page_sync() in the sync() system
call.

>revision 1.76
>date: 1997/02/13 02:54:06;  author: tls;  state: Exp;  lines: +2 -1
>sync needs to clean VM objects backed by vnode pagers

This call has the effect of using a large amount of CPU time. and since it
update (8) calls sync every 30 secs you will see a system pause every
30 seconds when update is running.

Closer inspectition reveals that a large number of pmap_enter() and
pmap_remove() calls are being made. Due to the virtual writeback cache on
the SA110 these calls trigger a lot of cache cleaning (which has to be
done in software) and it is this cleaning that is accumulating the system
CPU time.
 
>   Are there any ramifications to running without update? (I'm using the 
> machine mainly as an xterminal at the mo, i.e. not writing much to disk)

I would not recommend this.

being HACK HACK HACK

You would probably be better off commenting out the vnode_pager_sync()
call on line 453 (v1.78) of kern/vfs_syscalls.c
This will give you the sync behaviour we had before.

end HACK HACK HACK


The real solution is being worked on. A complete pmap rewrite is in the
pipeline that will be more aware of the writeback cache and the problems
that introduces (the orig pmap was written when there was only the ARm6
writethough cache). The rewrite will result in much more optimised and
efficient pmap code and this should reduce the ammount of cache cleaning
that will need to be done and thus will reduce the ammount of time spent
in the pmap_enter() and pmap_remove() routines.


Cheers,
				Mark