Operating Systems in Memory (I Wonder...)

[Haarsma, Michael (SAPOL)]

I don't disagree Mark, but im not advocating using tmpfs, im suggesting
a cheap hardware alternative, so memory management can still do its
thing with what RAM it has. If your speed issues are with initial load
times, no amount of buffering, caching, optimisation will help to the
degree of a SSD. It will only help once its been read into RAM in the
first place. In fact no writing to disk will ever really be as fast
either - unless you have a huge write cache and hope you never have a
crash or power outage.

I suggested a 'plug and play' option, no need to "..spend<snip> an
afternoon worth of hacky messing around" as you say, again something I
agree with, hence "Could be a handy option to look into David, that
doesn't involve bizarre scripts and additional complexity" so really I'm
not sure why you picked my post to Quote.. I don't disagree that inbuilt
memory management works just fine for 99% of cases, but David WANTS to
tinker (well I assume so, cause he seems to tinker with everything :)),
so why not suggest something he can tinker with?

Cheers,

Michael
 


> -----Original Message-----
> From: Richard Meyer [mailto:meyerri at westnet.com.au] 
> Sent: Friday, 15 December 2006 2:35 PM
> To: newton at atdot.dotat.org
> Cc: Haarsma, Michael (SAPOL); linuxsa at linuxsa.org.au
> Subject: Re: Operating Systems in Memory (I Wonder...)
> 
> 
> On Fri, 2006-12-15 at 12:55 +1030, Mark Newton wrote:
> > Haarsma, Michael (SAPOL) wrote:
> > 
> > > But with tmpfs on reboot you loose it (data, not mind). 
> The i-Will 
> > > you don't. Hence my suggestion to look into it. Might be 
> suitable, 
> > > if not, well its not, no harm looking :)
> > 
> > 
> > I think you're all kinda missing the point.
> > 
> > tmpfs is backed by virtual memory.  So if you run out of 
> RAM it gets 
> > swapped out and you're back to disk-based access anyway.
> > 
> > If you have lots of RAM, forget about tmpfs, just use the buffer 
> > cache.  The same blocks of data will end up in the same RAM, just 
> > without going through the additional overhead of the filesystem. On 
> > reboot you surely lose the buffer cache, but you read it 
> back in next 
> > time anyway so who cares?
> > 
> > I'm not quite sure why, but most of you guys in this thread seem 
> > hell-bent on micromanaging your systems' access to storage.  Forget 
> > it.  There are already plenty of mechanisms in the kernel which a 
> > whole bunch of people who are a lot smarter than you have 
> spent a hell 
> > of a lot of time making incredibly good.  It is highly 
> unlikely that 
> >  is spending an afternoon worth of hacky messing around
> going to come 
> > up with anything that's more efficient than what's already built-in.
> > 
> > If you want your disk access to go fast, buy more RAM to make the 
> > cache bigger.  Don't do what most people do, which is to buy enough 
> > RAM to hold your currently running applications.  Buy enough RAM to 
> > hold your currently running applications AND their datasets.  Then 
> > it'll be fast.  Greased lightning.  No additional work required.
> > 
> >    - mark
> 
> Got to agree with you, Mark. Most of my tuning experience has 
> been on mainframes, where it's BEST to allow the paging 
> system to look after things. Paging IO was so optimised, no 
> other types of IO came even close.
> 
> And if you have enough memory, it'll never fill up, and 
> eventually, everything you need will be there, after the first time.
> -- 
> Richard Meyer <meyerri at westnet.com.au>
> There are II types of people - those who can count like 
> Romans and those who can't.
> 
> Linux Counter user #306629
> 
>