[LUAU] Running a standard distro without swap space

[Jim Thompson]

On May 13, 2005, at 9:17 PM, Charles Lockhart wrote:

> Brian Chee wrote:
>
>> Actually I have a question...why would you want to run a machine 
>> without
>> swap? There are good reasons if you're running an embedded linux 
>> machine,
>> but for normal machines I've seen folks setup unix boxes that boot 
>> from the
>> network but ONLY do swap to the local hard disk. Those old xterms did 
>> this
>> alot just so that you don't swap over the network.
>>
> We're not using our machines as general desktop platforms.  They're 
> part of a system.  In the current case I'm looking at, the computer is 
> receiving data via a fiber link on one pci bus, processing that data, 
> and then writing the data to disk across a second pci bus while we're 
> still reading in more data over the first pci bus.  We've (hopefully) 
> managed to handle the contention issues internal to the program, but 
> we found that the system loses balance and starts dropping data 
> (irreplacable data) somewhat randomly if physical memory fills up and 
> the mm starts using the swap partition.  Basically the primary 
> application will be working fine, then we'll start up something other 
> stuff (slickedit, firefox, tkcvs, etc.), and at some point the swap 
> partition starts getting used and the primary application performance 
> starts being randomly flaky.  This would be fine if we had some big 
> shiny flag that would shoot up and alert the user that the system 
> needs to be re-balanced.  But we don't.
> One way that we could possibly fix this is to just disable the swap 
> partition.  I'd been hoping that new applications that would exceed 
> the physical memory on process load would just fail, flagging to the 
> user that they're misbehaving, but instead the machine just slows down 
> a lot.  This is slightly more problematic for how we use the system.
>
> I've also talked to other people that were designing instrumentation 
> for astronomy, and there interest in getting rid of the drives was 
> based on what I'm told is a high rate of disk failure at altitude.  If 
> the primary source of failure is the disk, then why have it?  But, 
> please somebody correct me if I'm wrong, no disk no swap space?

Man, you gotta love all the white-out on that black project tech.  :-)

Not all hard drives have disks, it turns out.   For (ahem) mil-spec 
(did I say that) applications at altitude (most folks don't know just 
how hard an airplane can vibrate under certain conditions.  This makes 
the heads hit the disks, which is... bad), some of the (cough) 
contractors with which I am familiar use various (battery backed) RAM 
or flash based disks.

Companies like BiTMICRO Networks, M-Systems and Texas Memory Systems 
all make IDE (or SCSI) based drives that are completely solid state.   
Might be worth thinking about, not so much for swap, but you're writing 
down that data *someplace* inside the airframe, no?

As for altitude without the (cough) "mobile platform" aspect (so no 
high cyclic rate, high-G vibrations), consumer grade drives can't 
stomach high altitude quite literally because the air is (too) thin, so 
the heads fly on a thinner cushion of air, and this is a bit too close. 
  Its a bummer.

As for keeping your application running while the VM system tries to be 
fair to firefox or slickedit:

1) which kernel are you running?
2) have you considered mlock()/mlockall()?
	(post 2.6.9 you don't have to be (e)uid==0 to successfully call 
mlock() and friends)
3) you might also look at sched_setscheduler() and friends (assuming 
linux 2.6 kernels)
4) for the truly time-critical application, you could look at RTLinux 
and friends.

#2 and #3 can probably be combined to ensure that its firefox, tkcvs 
and slickedit that get sick in
a low free pages situation.  You'll want to be careful to not livelock 
yourself, create priority inversion, etc.

You could also call setrlimit(RLIMIT_AS, ...) in the parent of any 
process that is likely to start firefox, tkcvs, etc.   This will smack 
any program that attempts to allocate over the limit you set.  If you 
want to be somewhat kinder, you could setrlimit(RLIMIT_RSS, ...) to 
limit the resident set of these "unclean" programs.   That will make 
the pager work harder, but if you've a) locked the critical 
pages/applications in core and b) told everyone else that can only have 
X MB (each) of resident pages, you might find a solution.

They're just ideas.

jim