🚀 go-pugleaf

In article <7963@lanl.ARPA> jlg@a.UUCP (Jim Giles) writes:
>In article <389@cci632.UUCP> rb@ccird1.UUCP (Rex Ballard) writes:
>>Most applications spend 90% of their time executing only 10% of their
>>code.  Interactive and transaction processing applications spend
>>nearly 95% of their time in a "wait for I/O, parse, loop" with an
>>occaisional "do special purpose 'case' processing".  There are more
>>than a few stories of such applications where swapping that involved
>>a loop smaller than 2K caused serious degradation due to the 64K to
>>1Mb "tails" that would get swapped in with them.
>>
>I've seen codes that spend 99% of their time in just 1-2% of the code.
>So what?  The code only occupies 2% of the memory image of the program.
>The rest of the memory image is data, and 90% of it is being processed
>repeatedly by that tight loop in the code.
>
>Yes, when you job mix is composed mainly of small and/or interactive
>processes, by all means you should have a VM system.  I question the
>need for VM in contexts where this is not true.
>
>J. Giles

Actually, when you have a lot of small processes, segmentation or
paging are about equal in terms of trade-offs, especially when
processes are extremely small.

When large tasks are being run in a multi-tasking environment,
the advantages of paging begin to be more dramatic.

If a task is run to completion without swapping, overlays, or
segmentation, and the OS is smart enough to prevent running
of more processes that is currently available, and each task
can be run in a reasonable amount of time (1/2 second or less),
and there is a separate processor to handle the I/O, then it
is possible to get superior performance.

Having some hands-on experience with all three types of systems,
most of my observations tend favor paging for multi-tasking.
100% memory resident subsystems are also a big win without paging.

Get a 300meg disk and a 300meg ram, treat shared data in the same
area, using signals, semaphores, and queues, "flush the world"
asynchronously, and the overhead becomes the drive interrupt handler.
Even under these conditions the "tagging" of memory references will
reduce the number of "flushes" since only those "pages" written to
since last flush are effected, rather than "read only this time around"
sectors.  Tagging can be done with software, but wouldn't be much
faster than hardware.

One of the "convincers" for me was seeing a "task segmented" system
running a bunch of "named pipe" transaction processing applications.
When the system was fully configured, over 200 tasks might be
running at the same time.  Every few seconds, the system would
go through the "Big swap", during which almost nothing else could
run.  Converting to a paged system actually increased performance
by a couple orders of magnitude, in spite of slower memory accesses
due to TLB translation.

Think about some of the "tails" that come with most well-written
applications.

Argument parsing - do it at start up, probably not used again.
Buffer initialization - you might not need this more than once.
File opening - one of those things you don't want to do too often.
Error handling - lot's of messages you hope you'll never use.
State machines - typically only one choice executed at a time.
Nested subroutines - Only the "active path" is needed.
Default linked libraries - Do you always use the floating point
	when you call printf().

Do you really want to swap all of that every time you have to swap?
Even ramdisk management schemes require the cost of copying in
the appropriate task, in it's entirety before executing.

If the avarage application on a system is only a modest 40K, the
working set in a task-segmented system is still limited to
a smaller number of tasks than in a paged system with even 4K
pages.

One feature I've always wanted to see is mapping of sharable
library executables in a paged system.  Popular subroutines
like "printf" are often very large (6-10K on some systems)
and usually not shared.

Disk cache paging can also be useful.  This is different from
CPU/memory access paging in that things like directory entries,
commonly used data files, and similar frequently used data can
be kept in core.  This is real handy when running several unix
shell scripts.