Karthik Karupasamy asked;

> How do I disable Page swapping? The intention is to
> reduce the latency in switching between tasks.
>
> Is it possible to install NetBSD without Swap
> partition?

As already answered, it's possible to run NetBSD without swap
partion(s) as page backing storage.  Some (including me) mistakenly
fail to prepare a swap partition and did not notice for long time until
RAM is really exausted and system started behaving badly.

It's a very classic argument how VM should behave when memory
staversion continues.  I have a literature named "Digal UNIX Technical
Overview" at hand and it refers DU, which itself is Mach VM
descendent, has two VM policy to respond memory shortage situation.
- Lazy allocation policy, and
- Eager reservation policy
Difference is the way physical memory is allocated when a process
demands it to run.  In lazy policy, backing storage is not assigned with
when that memory is going to use.  This means that if backing storage
is found little for that physical memory contents to be moved to backing
storage (page-out) to make room of runtime physical memory, the system
will have great difficulties about what should do to solve the situation.
Most systems are to kill process(es) to improve the resource shortage
deadlock.  So which process to shoot?  Longest living, or largest memory
consuming, or other shooting policy is used.
But, killing process(es) descrimately may be considered bad.   Let's
say you start long running  scientific calcuration program one evening and
go home expecting it will finish before dawn.  Next morning you might be
dissappointed to find the system is in short memory and your program
has not done yet.  Worse is it's not pre-determined which process(es) to
terminate for VM to go farther.
Eager allocation policy is to make sure the backing storage is bound with
physical memory which is going to allocated to process.  This sounds safer,
but not a perfect solution indeed.   It always consumes at least as large backing
storage as a process is planned to do so.  And unless the program is coded
carefully not to demand larger than pre-planned amount of memory, that is,
NOT demanding malloc() or larger stack storage during the mid stage of
entire process life time, dead locking backing storage shortage can happen
anyway.
So, Digital UNIX provides a choice between which policy is less worse for
you to accept.

Now, I would like to point that the way to use backing storage by UNIX kernel
has been evolved since its birth.  Modern UNIX VM is aggressive to utilize
physical memory.  UBC (unified buffer cache) is a part of the entire VM
activity which is orginally designed to make possible protected multi-programming
runtime since it's expected to contribute high efficient memory usage.  Modern
UNIX VM also allows an system to run w/o backing storage.  The feature was
realized some time ago, mid '80 of the last century when Mach VM or SunOS4
was a hot topic to debate in USENIX conference.   UNIX researchers argued
loudly the design issues of 4BSD VAX VM.  4BSD VAX VM always allocates
the same amount of backing storage when a process is going.  This means
process(es) actually run on swap space using physical memory is runtime
cache.  This is what VM is exactly expected at the time when designed.
Let's go back farther.  I've the original J. Lion's commentary literature printed by
Bell laboratory (it has Bell logo at a corner).   If people are patient enough to read
the acient UNIX kernel source code, he/she finds estabur() is doing a magic.
It's to do swap space allocation and "memory arbitor"  Swaper process behaves
a scheduler.  That's because UNIX has (had) no runtime context larger than
the number of processes given any time.  To make possible swapping activity a
shadow process was required.  It's a scheduler and a process swapper at the
same time.

So, it's a time to stop rumbling.  There is only a single solution to avoid memory
storage; to have large memory as possible.

Toru Nishimura/ALKYL Technology