Why all dat swapping out 'dere?

Fritz Wuehler · External Since: Mar 02, 2012 Posts: 9

A venerable Slackware 13.0 instaration (2.6.29.6 kernel) with 4G of
RAM. When it gets to about 1.5 or so gig it starts going to swap. Why
doesn't Linux use all the RAM before it starts swapping? It doesn't make
sense to me to see a few hundred meg of swap with 2 plus GIG RAM left and
performance suffer because of it. I could save money and install 2G RAM and
spend the rest on SSD! Slackware rox but Linux suxs? WTF is my problem?

Martin · External Since: Feb 01, 2010 Posts: 34

Fritz Wuehler wrote:

> A venerable Slackware 13.0 instaration (2.6.29.6 kernel) with 4G of
> RAM. When it gets to about 1.5 or so gig it starts going to swap. Why
> doesn't Linux use all the RAM before it starts swapping? It doesn't make
> sense to me to see a few hundred meg of swap with 2 plus GIG RAM left and
> performance suffer because of it. I could save money and install 2G RAM
> and spend the rest on SSD! Slackware rox but Linux suxs? WTF is my
> problem?

I agree it is totally brain donated but they won't listen to me. Wink

Anyway,
there is a parameter /proc/sys/vm/swappiness which you can optimize. Set it
to 0 or 10 at most. (Even Con Kolivas ships a 10 these days.)

Also consider removing the swap device altogether if you have enough RAM. I
had long and rude discussions with people about it, and I still don't see
the point, as long as enough RAM is vailable for the intended use.

A swap device extends the hard limit given by your RAM size, but it still
sets a hard limit and sends you into thrashing long before reaching it.
That's almost always the worse option compared to the OOM killer which is
quite clever these days in identifying the run-away application.

Floyd L. Davidson · External Since: Aug 24, 2006 Posts: 416

Fritz Wuehler wrote:
>A venerable Slackware 13.0 instaration (2.6.29.6 kernel) with 4G of
>RAM. When it gets to about 1.5 or so gig it starts going to swap. Why
>doesn't Linux use all the RAM before it starts swapping? It doesn't make
>sense to me to see a few hundred meg of swap with 2 plus GIG RAM left and
>performance suffer because of it. I could save money and install 2G RAM and
>spend the rest on SSD! Slackware rox but Linux suxs? WTF is my problem?

Did you notice what gets swapped out? And how the RAM
is actually used?

"Unused" RAM becomes a disk buffer to speed the system
up. It has an exremely dramatic effect. Some time do
something like "time find /usr > /dev/null" and see how
long it takes to find every single filename in the /usr
directory. Then do it again and see the effect of
caching! I just did it on one box here and the first
time took 32 seconds, the second invocation finished in
0.6 seconds!

That shows why you clearly want to free up as much RAM
as possible. One way to do that is to swap out all
program code that is not being used. If you check to
see what those few megabytes that are swapped out are,
it is all code that has been loaded with some program
that runs continuously, but never access that code. No
point in having it in memory...

--
Floyd L. Davidson <http://www.apaflo.com/>
Ukpeagvik (Barrow, Alaska) floyd.DeleteThis@apaflo.com

Chris Vine · External Since: Nov 03, 2004 Posts: 28

On Sun, 04 Mar 2012 19:37:32 +0100
Fritz Wuehler
wrote:
> A venerable Slackware 13.0 instaration (2.6.29.6 kernel) with 4G of
> RAM. When it gets to about 1.5 or so gig it starts going to swap. Why
> doesn't Linux use all the RAM before it starts swapping? It doesn't
> make sense to me to see a few hundred meg of swap with 2 plus GIG RAM
> left and performance suffer because of it. I could save money and
> install 2G RAM and spend the rest on SSD! Slackware rox but Linux
> suxs? WTF is my problem?

If you are using 32 bit slackware, the standard kernel (at least in my
slackware 13.37) does not enable physical address extension for
large (up to 16GB) RAM installations. This means that the most RAM you
are likely to be able to use with 32 bit slackware is in practice around
3GB: you won't get much closer than 3GB to the theoretical 4GB maximum
address space.

So you could either use slackware64, assuming you are not doing that
at present, or recompile your kernel with PAE enabled to reduce
swappiness.

In any event, such miniscule swapping is harmless. But even if that
were not so, your conclusion (that installing more than 2GB of RAM is
pointless) would not follow assuming you do enable PAE. If you do
something RAM intensive, you will soon notice the difference between
2GB and 4GB or RAM.

Chris

Michael Black · External Since: Jan 26, 2009 Posts: 80

On Sun, 4 Mar 2012, Floyd L. Davidson wrote:

> Fritz Wuehler wrote:
>> A venerable Slackware 13.0 instaration (2.6.29.6 kernel) with 4G of
>> RAM. When it gets to about 1.5 or so gig it starts going to swap. Why
>> doesn't Linux use all the RAM before it starts swapping? It doesn't make
>> sense to me to see a few hundred meg of swap with 2 plus GIG RAM left and
>> performance suffer because of it. I could save money and install 2G RAM and
>> spend the rest on SSD! Slackware rox but Linux suxs? WTF is my problem?
>
> Did you notice what gets swapped out? And how the RAM
> is actually used?
>
> "Unused" RAM becomes a disk buffer to speed the system
> up. It has an exremely dramatic effect. Some time do
> something like "time find /usr > /dev/null" and see how
> long it takes to find every single filename in the /usr
> directory. Then do it again and see the effect of
> caching! I just did it on one box here and the first
> time took 32 seconds, the second invocation finished in
> 0.6 seconds!
>
> That shows why you clearly want to free up as much RAM
> as possible. One way to do that is to swap out all
> program code that is not being used. If you check to
> see what those few megabytes that are swapped out are,
> it is all code that has been loaded with some program
> that runs continuously, but never access that code. No
> point in having it in memory...
>
Yes.

One time after an install, I forgot to set swap, there was the swap
partition and it appeared, but was never used. I didn't even think about
it until one conversation here, when I realized I'd forgotten a step. I
never seemed to suffer from the lack of swap, but I underuse my system.

But after that, it was common to see some swap used, a minor amount and
never seemed to get larger, or only got larger when I was actually doing
something RAM intensive (like doing a lot of Gimp). So it seemed that
some swap was basically used anyway.

I still have "only" 512megs of RAM, and while it's been only up for 24
days (a power outage), only 2656 bytes of swap is being used. That isn't
much, it has to either be some sort of bookkeeping, or it really is minor
swapping. I know when I've checked "free" from time to time, swap stays
about at that level, no real significant use.

It's not like in the old days when you absolutely needed swap because
there was only 8megs of RAM and if you wanted to do much you needed swap,
but even then "twice the amount of RAM" was the usual amount of swap
space. Then you likely would see a lot of swapping, and likely slow
swapping since a computer with 8megs of RAM likely didn't have a fast
buss, because it needed swap since RAM was limited.

But it would certainly seem that "no use of swap" isn't the norm, just
small use of swap.

Michael

Fritz Wuehler · External Since: Mar 02, 2012 Posts: 9

Martin wrote:

> Fritz Wuehler wrote:
>
> > A venerable Slackware 13.0 instaration (2.6.29.6 kernel) with 4G of
> > RAM. When it gets to about 1.5 or so gig it starts going to swap. Why
> > doesn't Linux use all the RAM before it starts swapping? It doesn't make
> > sense to me to see a few hundred meg of swap with 2 plus GIG RAM left and
> > performance suffer because of it. I could save money and install 2G RAM
> > and spend the rest on SSD! Slackware rox but Linux suxs? WTF is my
> > problem?
>
> I agree it is totally brain donated but they won't listen to me. Wink

Anyway,
> there is a parameter /proc/sys/vm/swappiness which you can optimize. Set it
> to 0 or 10 at most. (Even Con Kolivas ships a 10 these days.)

tanks i willing to give you a try

> Also consider removing the swap device altogether if you have enough RAM. I
> had long and rude discussions with people about it, and I still don't see
> the point, as long as enough RAM is vailable for the intended use.

I have always said this because even with much less RAM my Slack 10.2 and 11
and 12 never swapped but on 13.0 its swapping. I blame YOU mr linux kernel!
But I really don't know for certain who is the bastard swapping without an
excuse. I did try running with no swap but I had some leaky applrication and
sonbitch crash my Slack after week or so! Bastard!

> A swap device extends the hard limit given by your RAM size, but it still
> sets a hard limit and sends you into thrashing long before reaching it.

In only very bad case it should happen like that bro.

> That's almost always the worse option compared to the OOM killer which is
> quite clever these days in identifying the run-away application.

What' OOM killer? maybe turn him loose on linux kernel bug!

Floyd L. Davidson · External Since: Aug 24, 2006 Posts: 416

Martin wrote:
>Fritz Wuehler wrote:
>
>> But I really don't know for certain who is the bastard swapping
>> without an excuse.
>
>it's a policy decision controlled by /proc/sys/vm/swappiness as mentioned
>before. Why on earth anyone would want a policy that starts swapping before
>the physical RAM is exausted is beyond me.
>
>Some people (even in this thread) argue that having a larger block buffer at
>the expense of process memory is advantageous, but I seriously doubt anyone
>can construct a use case and a measurement to prove it. The reason is the
>strict LRU nature of the block buffer that makes it the prime candidate for
>eviction.

That it is so for the average workstation has been well measure and
documented.

If the unused code is swapped out, as a low priorit process, well before
the absolute need for the RAM it is allocated to arises it can in fact be done
as a low priority that does not affect system performance. On the other hand,
waiting until the RAM is needed means it has to be accomplished in competition
with high priority processes, and must be pushed to the top of the priority
list. That affects system performance in a very noticeable way, and should be
avoided.

>
>> I did try running with no swap but I had some leaky
>> applrication and sonbitch crash my Slack after week or so! Bastard!
>
>cf. below
>
>>> A swap device extends the hard limit given by your RAM size, but it still
>>> sets a hard limit and sends you into thrashing long before reaching it.
>>
>> In only very bad case it should happen like that bro.
>
>Can't help it. Whenever a system goes into swapping I notice it, and I hate
>it. Unless there is a good reason (like you simply NEED more RAM than
>physically available).
>
>>
>>> That's almost always the worse option compared to the OOM killer which is
>>> quite clever these days in identifying the run-away application.
>>
>> What' OOM killer? maybe turn him loose on linux kernel bug!
>
>The OOM (out-of-memory) killer is the kernel function that selects a process
>and kills it at times of memory starvation. Nowadays it is often successful
>in detecting the run-away process (if there is one), but admittedly there is
>a random element and it might kill your X server. :p

And while his example of a system with no swap show him
very quickly that there was a memory leak, in fact even
a system with a large amount of swap space would
eventually run dry and demonstrate that a memory leak
existed.

--
Floyd L. Davidson <http://www.apaflo.com/>
Ukpeagvik (Barrow, Alaska) floyd.TakeThisOut@apaflo.com

Martin · External Since: Feb 01, 2010 Posts: 34

Fritz Wuehler wrote:

> But I really don't know for certain who is the bastard swapping
> without an excuse.

it's a policy decision controlled by /proc/sys/vm/swappiness as mentioned
before. Why on earth anyone would want a policy that starts swapping before
the physical RAM is exausted is beyond me.

Some people (even in this thread) argue that having a larger block buffer at
the expense of process memory is advantageous, but I seriously doubt anyone
can construct a use case and a measurement to prove it. The reason is the
strict LRU nature of the block buffer that makes it the prime candidate for
eviction.

> I did try running with no swap but I had some leaky
> applrication and sonbitch crash my Slack after week or so! Bastard!

cf. below

>> A swap device extends the hard limit given by your RAM size, but it still
>> sets a hard limit and sends you into thrashing long before reaching it.
>
> In only very bad case it should happen like that bro.

Can't help it. Whenever a system goes into swapping I notice it, and I hate
it. Unless there is a good reason (like you simply NEED more RAM than
physically available).

>
>> That's almost always the worse option compared to the OOM killer which is
>> quite clever these days in identifying the run-away application.
>
> What' OOM killer? maybe turn him loose on linux kernel bug!

The OOM (out-of-memory) killer is the kernel function that selects a process
and kills it at times of memory starvation. Nowadays it is often successful
in detecting the run-away process (if there is one), but admittedly there is
a random element and it might kill your X server. :p

Henrik Carlqvist · External Since: Aug 07, 2005 Posts: 869

Fritz Wuehler
wrote:
> Yeah its significant bro cuz the system starts sucking wind when it swap no
> matter how rittle swap he used, there aint no excuse for swapping. linux
> kernel sux, its broken its stupid.

People here have been trying to convince you about the benefits of
swapping out unused code _before_ the RAM is needed, but you still seem
sure that swapping it is necessary is a bad idea.

Likewise you have been trying to argue that swapping before necessary is a
bad idea while most other people still agree that it gives better
performance.

Why not settle this once and for all? It is very easy to enable and
disable swap and reboot. With that configuration change, do you have any
single benchmark that shows you how much faster your system gets with swap
disabled? Things you might want to test could be:

Time from lilo starts loading the kernel until you get the login prompt.
Time to start some application for the first time.
Time to start the same application again for the second time.

Please do some testing, the show us exactly how much this swapping sux.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

Floyd L. Davidson · External Since: Aug 24, 2006 Posts: 416

Dan C wrote:
>On Mon, 05 Mar 2012 11:44:24 -0900, Floyd L. Davidson wrote:
>
>> The babe here that is sucking, friend... is Fritz.
>
>And yet...... you keep replying to the obvious troll.

Hmmmmm... I quite before you did!

--
Floyd L. Davidson <http://www.apaflo.com/>
Ukpeagvik (Barrow, Alaska) floyd DeleteThis @apaflo.com

Floyd L. Davidson · External Since: Aug 24, 2006 Posts: 416

Martin wrote:
>Floyd L. Davidson wrote:
>
>> If the unused code is swapped out, as a low priorit process, well before
>> the absolute need for the RAM it is allocated to arises it can in fact be
>> done
>> as a low priority that does not affect system performance.
>
>that is a false assumption as every I/O on a rotational disk is harmful to
>performance, particularly if your swap device is on the same disk as the
>partition being accessed by other processes concurrently. And you have the
>cost of swapping the pages back in.

No it is not a false assumption, it is a well researched
fact. 1 write to swap when the cpu is otherwise idle
does not slow anything down. But have freed up that
much RAM allows perhaps thousands of reads from disk to
be avoided...

What you are missing is that the above is *not* talking
about anything that is repetitive. It happens once.

>> On the other
>> hand, waiting until the RAM is needed means it has to be accomplished in
>> competition with high priority processes, and must be pushed to the top of
>> the priority
>> list. That affects system performance in a very noticeable way, and
>> should be avoided.
>
>no doubt theoretical scenarios can be constructed, but I dare say in the
>majority of cases the pull principle is superior (in the sense of lean or
>just-in-time production).

No doubt the way that it is in fact configured has
certainly been examined in detail! It's actually fairly
obvious in course terms, and the real problem is
deciding how much RAM makes it a relatively
non-productive exercise.

--
Floyd L. Davidson <http://www.apaflo.com/>
Ukpeagvik (Barrow, Alaska) floyd.DeleteThis@apaflo.com

Dan C · External Since: Nov 26, 2006 Posts: 718

On Mon, 05 Mar 2012 11:44:24 -0900, Floyd L. Davidson wrote:

> The babe here that is sucking, friend... is Fritz.

And yet...... you keep replying to the obvious troll.

--
"Ubuntu" -- an African word, meaning "Slackware is too hard for me".
"Bother!" said Pooh, as he inhaled.
Usenet Improvement Project: http://twovoyagers.com/improve-usenet.org/
Thanks, Obama: http://brandybuck.site40.net/pics/politica/thanks.jpg

Fritz Wuehler · External Since: Mar 02, 2012 Posts: 9

floyd DeleteThis @apaflo.com (Floyd L. Davidson) wrote:

> Martin wrote:
> >Fritz Wuehler wrote:
> >
> >> But I really don't know for certain who is the bastard swapping
> >> without an excuse.
> >
> >it's a policy decision controlled by /proc/sys/vm/swappiness as mentioned
> >before. Why on earth anyone would want a policy that starts swapping before
> >the physical RAM is exausted is beyond me.
> >
> >Some people (even in this thread) argue that having a larger block buffer at
> >the expense of process memory is advantageous, but I seriously doubt anyone
> >can construct a use case and a measurement to prove it. The reason is the
> >strict LRU nature of the block buffer that makes it the prime candidate for
> >eviction.
>
> That it is so for the average workstation has been well measure and
> documented.
>
> If the unused code is swapped out, as a low priorit process, well before
> the absolute need for the RAM it is allocated to arises it can in fact be done
> as a low priority that does not affect system performance. On the other hand,
> waiting until the RAM is needed means it has to be accomplished in competition
> with high priority processes, and must be pushed to the top of the priority
> list. That affects system performance in a very noticeable way, and should be
> avoided.
>
> >
> >> I did try running with no swap but I had some leaky
> >> applrication and sonbitch crash my Slack after week or so! Bastard!
> >
> >cf. below
> >
> >>> A swap device extends the hard limit given by your RAM size, but it still
> >>> sets a hard limit and sends you into thrashing long before reaching it.
> >>
> >> In only very bad case it should happen like that bro.
> >
> >Can't help it. Whenever a system goes into swapping I notice it, and I hate
> >it. Unless there is a good reason (like you simply NEED more RAM than
> >physically available).
> >
> >>
> >>> That's almost always the worse option compared to the OOM killer which is
> >>> quite clever these days in identifying the run-away application.
> >>
> >> What' OOM killer? maybe turn him loose on linux kernel bug!
> >
> >The OOM (out-of-memory) killer is the kernel function that selects a process
> >and kills it at times of memory starvation. Nowadays it is often successful
> >in detecting the run-away process (if there is one), but admittedly there is
> >a random element and it might kill your X server. :p
>
> And while his example of a system with no swap show him
> very quickly that there was a memory leak, in fact even
> a system with a large amount of swap space would
> eventually run dry and demonstrate that a memory leak
> existed.

yeah babe but i ditched that bad applecation and now i be running with
swappiness minimization goin fo me an a day later it aint swapping no way no
how and i gots plenty o'ram 2 spare life is go when u aint doin no
illegitimate swappin

Fritz Wuehler · External Since: Mar 02, 2012 Posts: 9

Chris Vine wrote:

> On Sun, 04 Mar 2012 19:37:32 +0100
> Fritz Wuehler
> wrote:
> > A venerable Slackware 13.0 instaration (2.6.29.6 kernel) with 4G of
> > RAM. When it gets to about 1.5 or so gig it starts going to swap. Why
> > doesn't Linux use all the RAM before it starts swapping? It doesn't
> > make sense to me to see a few hundred meg of swap with 2 plus GIG RAM
> > left and performance suffer because of it. I could save money and
> > install 2G RAM and spend the rest on SSD! Slackware rox but Linux
> > suxs? WTF is my problem?
>
> If you are using 32 bit slackware, the standard kernel (at least in my
> slackware 13.37) does not enable physical address extension for
> large (up to 16GB) RAM installations. This means that the most RAM you
> are likely to be able to use with 32 bit slackware is in practice around
> 3GB: you won't get much closer than 3GB to the theoretical 4GB maximum
> address space.

t9oo rite bro my bad. i am using exclusivery slack 64! he see all my rams!

> So you could either use slackware64, assuming you are not doing that
> at present, or recompile your kernel with PAE enabled to reduce
> swappiness.

I blame mr linux kernel, he swap without a license motherfluker! I have
Slack64 and 4G Ram and only 1.6 or 1.8 used and bam he start swapping for no
good reason...somebody gonna pay for this.

> In any event, such miniscule swapping is harmless. But even if that
> were not so, your conclusion (that installing more than 2GB of RAM is
> pointless) would not follow assuming you do enable PAE. If you do
> something RAM intensive, you will soon notice the difference between
> 2GB and 4GB or RAM.

Yeah bro i notice it bigtime, the kernel start eating my swap and my system
slow down to a croll and when i switch apps its like go and get
coffee. Something is rotten in denmark. I love Slack but I hate linux
kernels. Maybe its time for new OS....

Martin · External Since: Feb 01, 2010 Posts: 34

Floyd L. Davidson wrote:

> If the unused code is swapped out, as a low priorit process, well before
> the absolute need for the RAM it is allocated to arises it can in fact be
> done
> as a low priority that does not affect system performance.

that is a false assumption as every I/O on a rotational disk is harmful to
performance, particularly if your swap device is on the same disk as the
partition being accessed by other processes concurrently. And you have the
cost of swapping the pages back in.

> On the other
> hand, waiting until the RAM is needed means it has to be accomplished in
> competition with high priority processes, and must be pushed to the top of
> the priority
> list. That affects system performance in a very noticeable way, and
> should be avoided.

no doubt theoretical scenarios can be constructed, but I dare say in the
majority of cases the pull principle is superior (in the sense of lean or
just-in-time production).

Fritz Wuehler · External Since: Mar 02, 2012 Posts: 9

Henrik Carlqvist wrote:

> Fritz Wuehler
> wrote:
> > Yeah its significant bro cuz the system starts sucking wind when it swap no
> > matter how rittle swap he used, there aint no excuse for swapping. linux
> > kernel sux, its broken its stupid.
>
> People here have been trying to convince you about the benefits of
> swapping out unused code _before_ the RAM is needed, but you still seem
> sure that swapping it is necessary is a bad idea.

hay well come 2 the frey

the issue my slackin bro is linux does a super bad job of guessing what is
_unused_

if linux could ever get it rite

that is what is _unused_code_

then yeah baby put it out there

put it ALL out there

but until that one fine day

and you gots mo ram to give

then all yo' guessin' is wrong and u be swappin yo life away

keep on rammin it

keep on rammin it

keep it in

keep it ALL in

keep it ALL in ram

> Likewise you have been trying to argue that swapping before necessary is a
> bad idea while most other people still agree that it gives better
> performance.

NOBODY says it gives better peformnance bro, it's only FLLOYRY, my homie
MARTIN agrees with MY WORD, SWAPPIN IS BAD ALL THE TIME

its a LAST resort bro
DONT BE swappin from the get go
do it when u GOTS 2
not just GRATUISTO

> Why not settle this once and for all? It is very easy to enable and
> disable swap and reboot. With that configuration change, do you have any
> single benchmark that shows you how much faster your system gets with swap
> disabled? Things you might want to test could be:
>
> Time from lilo starts loading the kernel until you get the login prompt.

> Time to start some application for the first time.
> Time to start the same application again for the second time.
>

you have rite the is a need 2 test
but none of your suggest puts it to the test
the quest is how responsive it be
in normal operativity
and the answer as we know
is turn off swap my bro
that is what i did
and slack is rockin like a kid
its back to in the day
when my ram would rule ur day

> Please do some testing, the show us exactly how much this swapping sux.

turn it off and tell yourself how much swapping sux
watch ur system hum
yeah baby yeah

Floyd L. Davidson · External Since: Aug 24, 2006 Posts: 416

Martin wrote:
>Floyd L. Davidson wrote:
>
>> Martin wrote:
>>>Floyd L. Davidson wrote:
>>>
>>>> If the unused code is swapped out, as a low priorit process, well before
>>>> the absolute need for the RAM it is allocated to arises it can in fact
>>>> be done
>>>> as a low priority that does not affect system performance.
>>>
>>>that is a false assumption as every I/O on a rotational disk is harmful to
>>>performance, particularly if your swap device is on the same disk as the
>>>partition being accessed by other processes concurrently. And you have the
>>>cost of swapping the pages back in.
>>
>> No it is not a false assumption, it is a well researched
>> fact. 1 write to swap when the cpu is otherwise idle
>> does not slow anything down. But have freed up that
>> much RAM allows perhaps thousands of reads from disk to
>> be avoided...
>
>care to show me this "research"?

Do your own research. This is was a hot topic a couple
decades ago, and is well settled.

>bear in mind that accessing the swap device is inherently seeky.

So what? It only happens 1 time. This is not
repetitive. It's a one shot occurance. In fact, it
does not involve any disk activity.

>Rotational
>disks are the slowest components by magnitudes, ie. we are talking about
>I/Os in the magnitude of MILLISECONDS. If another I/O request comes along
>during that time you WILL have a delay.

Disk i/o is cached, and the system orders i/o activity.
More over, so do the disks themselves!

Even if we were talking about swapping due to virtual
memory requirements, what you are saying is still not
true. But this is about swapping out *unused* *program*
code to free up RAM to be used as disk cache.

The fact is, *there is no physical write to disk
invovled*. The RAM pages used are marked as available,
and may be used for other purposes. That particular bit
of program data at that point is no longer in memory, it
is instead referenced in the executable file. The only
time there would be a physical disk i/o would be if it
is in fact used again by the program and has to read
back into RAM.

>If the partition is on the same
>platter not only do you need to seek to it, chances are the read/write head
>is positioned over there when it is needed elsewhere. Don't tell me all that
>is free. And come the next context switch, the page may have to be swapped
>back in.

Physical i/o is pre-ordered for efficiency by both the
disk and the system. But we are talking about program
code that is *not* being used. It takes days of
inactivity before it is "swapped out" in the first
place.

>I am not denying that there may be mathematical scenarios where the global
>maximum involves pre-emptive eviction of pages. However, since no agent can
>look into the future I severly doubt any such global optimization function
>can be implemented in the kernel.

Do some research. It has been there for years.

>In industrial production it has been proven empirically that lean production
>is the most efficient way of utilising resources (much more efficient then
>any "advance planning" methods). One element of lean production is: don't do
>costly operations (or any for that matter) unless there is an actual need
>for it (some agent "pulls" it).

Do some research. People have earned PhD's studying
this stuff.

>> What you are missing is that the above is *not* talking
>> about anything that is repetitive. It happens once.
>
>really.

Really. And it does *not* involve any physical writes
to the disk.

Here is a screen capture that might shine some light:

pix:floyd ~ 0>free
total used free shared buffers cached
Mem: 14032548 13696792 335756 0 346984 12811612
-/+ buffers/cache: 538196 13494352
Swap: 10249464 2528 10246936
pix:floyd ~ 0>uptime
13:24:44 up 271 days, 1:41, 7 users, load average: 3.18, 2.22, 1.35
pix:floyd ~ 0>

That is a file server. It has 14 GB of RAM, and about 7
or 8 TB of disk. As you can see, about 2.5Mb of swap is
being used. That same 2.5Mb has been swapped out for
nearly the entire 271 days the system has been up.
There is about 13 GB being used as disk buffer/cache.

Note that rather clearly, with the usage shown there it
would be possible to run the system with no swap at all.
But once in great while I use it for a compute server
too, and load it with processes. For safety's sake, it
has 10 Gb of swap. This is a 32 bit system, so
processes can only occupy 4GB of address space, plus the
10 GB of virtual memory as swap. If that were to happen
there would still be 10 Gb of RAM available for disk
cache.

Interesting configuration...

--
Floyd L. Davidson <http://www.apaflo.com/>
Ukpeagvik (Barrow, Alaska) floyd RemoveThis @apaflo.com

Henrik Carlqvist · External Since: Aug 07, 2005 Posts: 869

Fritz Wuehler
wrote:
> turn it off and tell yourself how much swapping sux

Unfortunately I can do no such test myself. I have Slackware64 13.1 with
this configuration on my home system:

minotaur:~> uptime
19:10:38 up 10 days, 17:10, 42 users, load average: 0.08, 0.03, 0.01
minotaur:~> free
total used free shared buffers cached
Mem: 8102588 2562276 5540312 0 390480 1140080
-/+ buffers/cache: 1031716 7070872
Swap: 49158892 0 49158892

As you can see, even though I have plenty of swap configured none of it is
used. I also have lots of RAM free, this probably explains why the swap
has not been used yet.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

Martin · External Since: Feb 01, 2010 Posts: 34

Floyd L. Davidson wrote:

> Martin wrote:
>>Floyd L. Davidson wrote:
>>
>>> If the unused code is swapped out, as a low priorit process, well before
>>> the absolute need for the RAM it is allocated to arises it can in fact
>>> be done
>>> as a low priority that does not affect system performance.
>>
>>that is a false assumption as every I/O on a rotational disk is harmful to
>>performance, particularly if your swap device is on the same disk as the
>>partition being accessed by other processes concurrently. And you have the
>>cost of swapping the pages back in.
>
> No it is not a false assumption, it is a well researched
> fact. 1 write to swap when the cpu is otherwise idle
> does not slow anything down. But have freed up that
> much RAM allows perhaps thousands of reads from disk to
> be avoided...

care to show me this "research"?

bear in mind that accessing the swap device is inherently seeky. Rotational
disks are the slowest components by magnitudes, ie. we are talking about
I/Os in the magnitude of MILLISECONDS. If another I/O request comes along
during that time you WILL have a delay. If the partition is on the same
platter not only do you need to seek to it, chances are the read/write head
is positioned over there when it is needed elsewhere. Don't tell me all that
is free. And come the next context switch, the page may have to be swapped
back in.

I am not denying that there may be mathematical scenarios where the global
maximum involves pre-emptive eviction of pages. However, since no agent can
look into the future I severly doubt any such global optimization function
can be implemented in the kernel.

In industrial production it has been proven empirically that lean production
is the most efficient way of utilising resources (much more efficient then
any "advance planning" methods). One element of lean production is: don't do
costly operations (or any for that matter) unless there is an actual need
for it (some agent "pulls" it).

> What you are missing is that the above is *not* talking
> about anything that is repetitive. It happens once.

really.

Fritz Wuehler · External Since: Mar 02, 2012 Posts: 9

Henrik Carlqvist wrote:

> Fritz Wuehler
> wrote:
> > turn it off and tell yourself how much swapping sux
>
> Unfortunately I can do no such test myself.

sure u can bro

swapoff -a

will turn all swap off

and swapon -a will put it all back on again