Problems reclaiming VM cache = XFree86 startup annoyance

[Matthew Dillon]

:...
:> (Paul Mather)
:> As you can probably gather, all this manual intervention is a bit of a
:> hassle.  So, my question is this: is there a way explicitly to force
:> the kernel to flush its VM cache (to move it to "Free").  Failing
:> that, are there any sysctls to tune to help alleviate the problem?
:> The only sysctls I change in /etc/sysctl.conf are as follows:
:
:(DG)
:   I don't know what is causing your problem, but 'cache' pages in FreeBSD
:are free pages - they can be allocated directly in the page allocation code.
:They only differ from "free" pages in that they contain cached file data.
:   So the number of pages 'cache' vs. 'free' isn't the cause of the problem.
:...

    Other disk activity can interfere with swap performance.  If these other
    background jobs Paul is running are doing a lot of disk I/O or using a 
    lot of memory, regardless of their nice value, they could be causing a
    significant reduction in swap I/O performance and/or be causing page
    thrashing.  The 'swwrt' state is waiting for an I/O to complete, *NOT*
    waiting for a memory allocation, which implies an I/O performance issue.

    It is likely that nothing is frozen per-say, just that I/O performance
    is insufficient to handle the paging load caused by starting X *AND*
    the I/O/memory load of whatever other background processes are running.
    When you ^Z the background process, the I/O it is performing stops which
    allows the paging I/O being caused by the X startup to get 100% of 
    available disk bandwidth.  Also remember that in an I/O bound situation,
    the 'nice' value of a process becomes irrelevant because there is plenty
    of cpu available due to all the processes being predominantly in a
    blocking state on I/O.

    The easiest solution is to add more memory to the machine.  It is fairly
    obvious to me that the machine does not have enough for the workload
    being thrown at it.  Alternatively you may wish to examine the memory and
    I/O footprint of these nice +20 processes and take steps to significantly
    reduce both.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>