🚀 go-pugleaf

>In article <1992Oct11.094702.3509@cubetech.com> andrew@cubetech.com writes:
>>In article <dillon.0ox5@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes:
>>In article <1992Oct6.160854.19152@cubetech.com> andrew@cubetech.com (Andrew Loewenstern) writes:
>>......

>>    The NeXT has some *serious* problems with it's paging and file caching
>>    (and I've mailed bug_next with specific examples).  Adding so much
>>    memory to your machine that you are essentially completely defeating
>>    demand paged virtual memory is not a solution.  No matter how much
>>    memory you have, when the NeXT eventually pages something it usually
>>    pages the WRONG something and the machine hicups.
>
>Like what??  Mach has a *killer* VM system.

    Write a program which writes a lot of crap to disk... say, writes 16
    one megabyte files, deletes them, then starts over (on a 16 MB
    machine).

    Run two of these programs in the background.  The result is that the
    rest of the machine locks up until the programs complete their
    execution.	(when you write the program, make sure it times out after a
    while so you don't have to command-tilde your machine).

    Mach cannot discern between file caching and program paging because it
    uses the same mechanism for both.  If you have a program, such as a
    compiler, which access a huge number of files, the rest of the machine
    slows down inordinately for several reasons:

    (1) Mach contains no priority mechanism to handle paging relating to
	the files the compiler is accessing and executable/data pages other
	programs need paged-in to simply run.

    (2) Mach indiscriminately puts pages on the inactive list that are
	not inactive.  It will happily steal the page out from under a
	running program to use for another running program, completely
	ignoring inactive pages in programs which have been sleeping for 10
	minutes.

    (3) On a 16MB machine I have found that mach tends to allocate on the
	ups of 6MB for caching files before it starts reusing file cache
	pages (that is, writing a program to access files with open() and
	read()/write() mach will keep about 6MB worth of the most recently
	cached files around).  Simply put, it's too much.  It wouldn't be
	so bad if Mach did not use pages out from under running programs,
	but it does.

    (4) Mach ignores relative process priority when it comes to paging.
	A LOW priority but disk intensive process can bring the rest of the
	machine to a screeching halt because it attempts to steal megabytes
	worth of pages from higher priority running processes.	This in
	turn causes the higher priority processes to temporarily halt
	waiting for a pagein thus giving the LOW priority process even more
	CPU.

    pagein/pageout activity is not prioritized based on process priority
    nor is it prioritized based on importance (file IO paging verses
    program code/data paging).	In fact, it isn't prioritized at all.

    Well, you asked...	and keep in mind that so far I have been running
    ONLY NeXT supplied programs... interface builder, edit, draw, gcc,
    etc...  If I start a compile nice +20 the rest of the machine becomes
    extremely jerky and, frankly, that should NOT happen!.

					    -Matt

>andrew
>--
>andrew@cubetech.com	 | "We shall not cease from exploration
>Andrew Loewenstern	 |  And the end of our exploring
>Cube Technologies, Inc. |  Will be to arrive where we started
>			 |  And know the place for the first time." -T.S. Eliot

--

    Matthew Dillon		dillon@Overload.Berkeley.CA.US
    1005 Apollo Way		uunet.uu.net!overload!dillon
    Incline Village, NV. 89451	ham: KC6LVW (no mail drop)
    USA 			Sandel-Avery Engineering (702)831-8000