Conference turris::digital_unix

10062.0. "problem with system freeze caused by sync after mmap and memcpy" by RDGENG::CHAMBERLIN (Danger! Do not Reverse Polarity) Fri Jun 06 1997 04:50

This is perhaps a follow on to notes 5065 and 4393.

Im looking into performance problems reported by a partner who produces a
graphics image editor. They reported systems frrezing for over 10 seconds after
performing multiple image copies (or a single large ~ 100 Mbyte copy). This is
not specific to any version of the OS version (3.2G or 4.0x), and is worse with
higher performance workstations.

I've been able to reproduce the problem with their application, and also with a
simple  demo which recreates the method they use - mmap the input and output
files and memcpy between them. Whilst the memcpy is extreemly fast on Alpha, the
data has to be backed up to the UFS disk at some time, and when sync comes along
to write out the 80-100 Mb, then this is when the system freezes for 10-20
seconds to user input. The freeze seems to be worse on faster workstations (AS
500/500 with rz28's) than on an older flamingo. Using vmubc, I notice that most
of the freeze time on the AS 500, the cpu is waiting (for i/o?).

Can any one suggest a method of stopping the system freezing whilst syncing?
Obviously we cant stop the update process, since the data needs to be written,
but the writes need to be done in the background so that user input is not
frozen out.

I repeated the tests using AdvFS instead of UFS. It seems that the write out is
performed more synchronously with the memcpy commands, rather than waiting for
sync. iostat shows many thousand disk io, whereas with UFS there are very few.
Hence we dont get the systen freeze, but the actual copies take much longer. I'm
not sure if this is better or not, but it is probably not an acceptable solution.

I also tried using msync after the memcpy's - this does prevent the freeze, but
of course the copies again take considerably longer.

Of course, this application doesn't suffer these problems on SGI, AIX or Solaris
etc, and the problem is impacting Alpha sales.....

Thanks,

		Ian Chamberlin,

			Software Partner Engineering (UK)

    
    Hi, Ian. 
    
    By default the ubc-maxpercent attribute in the vm subsystem can
    consume 100 % of available memory. I've lowered this to somewhere
    between 30-50% on some machines and it has helped with similar issues.
    This will tend to spread the writes out so that it's not all done when
    update sync's the disks. This may or may not help depending on how much
    memory you have on the machine - it might just make the system seem
    more sluggish overall. It is a general problem with mmap(2) and/or
    using POSIX shared memory - which relies on mmap(2). 
    
    Maybe someone else can offer other suggestions too?
    
    Hth, 
    
    Lee