Linus has spoken, and 2.4.x now requires swap = 2x RAM.
But, the 2GB per swap partition limit still exists, best as we can tell.
So, we sell machines with say 8GB RAM. We need 16GB swap, but really we
need like an 18GB disk with 8 2GB swap partitions, or ideally 8 disks with a
2GB swap partition on each. That's ugly.
Is the 2GB per swap partition going to go away any time soon?
Thanks,
Matt
--
Matt Domsch
Dell Linux Systems Group
Linux OS Development
http://www.dell.com/linux
[email protected] wrote:
> Linus has spoken, and 2.4.x now requires swap = 2x RAM.
> But, the 2GB per swap partition limit still exists, best as we can tell.
> So, we sell machines with say 8GB RAM. We need 16GB swap, but really we
> need like an 18GB disk with 8 2GB swap partitions, or ideally 8 disks with a
> 2GB swap partition on each. That's ugly.
>
> Is the 2GB per swap partition going to go away any time soon?
>
> Thanks,
> Matt
>
I know Rik have some plans but I don't know the time table.
On the other hand do you really need swap partitions how about using swap
files? That way you don't need to manage alot of partitons and you can test if
you really do need to go all the way to 2xRAM. It dose look a bit silly to have
16GB swap. Are you really going to load the machine with work that needs more
than 8GB?? if not you don't really need any swap.
I have not created any swap partitons in years and mostly run without any swap
whatsoever. It's easy to create one temporary if I know I'am going to use more
memory than I have. Obviously on a server it's better to be safe than sorry.
On Fri, 2 Mar 2001 [email protected] wrote:
> Linus has spoken, and 2.4.x now requires swap = 2x RAM.
I think I missed this. What possible value does this have? (Not even
Sun, the original purveyors of the 2x RAM rule, need this any more).
> > > Linus has spoken, and 2.4.x now requires swap = 2x RAM.
> >
> > I think I missed this. What possible value does this have?
A good write-up of the discussion can be found at:
http://kt.zork.net/kernel-traffic/kt20010126_104.html#2
My concern is that if there continues to be a 2GB swap partition/file size
limitation, and you can have (as currently #defined) 8 swap partitions,
you're limited to 16GB swap, which then follows a max of 8GB RAM. We'd like
to sell servers with 32GB or 64GB RAM to customers who request such for
their applications. Such customers generally have no problem purchasing
additional disks to be used for swap, likely on a hardware RAID controller.
We've also seen (anecdotal evidence here) cases where a kernel panics, which
we believe may have to do with having 0 < swap < 2x RAM. We're
investigating further.
> Actually the deal is: either use enough swap (about 2x RAM) or use
> none at all.
If swap space isn't required in all cases, great! We'll encourage the use
of swap files as needed, rather than swap partitions. But, if instead you
*require* swap = 2x RAM, then the 2GB swap size limitation must go.
Thanks,
Matt
--
Matt Domsch
Dell Linux Systems Group
Linux OS Development
http://www.dell.com/linux
Hi Matt,
On Sun, 4 Mar 2001, Matt Domsch wrote:
> My concern is that if there continues to be a 2GB swap
> partition/file size limitation, and you can have (as currently
> #defined) 8 swap partitions, you're limited to 16GB swap, which then
> follows a max of 8GB RAM. We'd like to sell servers with 32GB or
> 64GB RAM to customers who request such for their applications. Such
> customers generally have no problem purchasing additional disks to
> be used for swap, likely on a hardware RAID controller.
I did think about that too and I also think the 2GB limit is not
appropriate for the big servers. But I do not beleive that you need so
much swap on these machines. If you drive a 32 GB machine so heavily
into swap it is more busy finding the pages to swap than doing
anything really interesting. (At least that's my experience)
BTW often these big servers run databases and application servers
which have most of their memory in shared memory. Shared memory does
free the swap entries on swapin. (I thought about changing that but as
long as we have no garbage collection for idle swap entries I will not
do it)
On any loaded server you have to check the swap space requirements
regularly and adjust to your needs. But to setup more than let's
say 8GB swap is a waste of resource IMHO.
> We've also seen (anecdotal evidence here) cases where a kernel
> panics, which we believe may have to do with having 0 < swap < 2x
> RAM. We're investigating further.
That would be a kernel bug which should be fixed. The kernel should
handle oom/oos.
>> Actually the deal is: either use enough swap (about 2x RAM) or use
>> none at all.
>
> If swap space isn't required in all cases, great! We'll encourage
> the use of swap files as needed, rather than swap partitions. But,
> if instead you *require* swap = 2x RAM, then the 2GB swap size
> limitation must go.
No it is not strictly required.
But still the 2GB limit is annoying and together with the
arch-independent maximum number of swap partitions/files it is pretty
dumb.
So I would propose to first make a small patch to make MAX_SWAPFILES
arch-dependent and bigger. (x86 would allow a muc higher
MAX_SWAPFILES)
For 2.5 we could perhaps think about a new swapfile layout which
allows bigger partitions.
Greetings
Christoph
Hi Matt,
In article <[email protected]> you wrote:
> My concern is that if there continues to be a 2GB swap partition/file size
> limitation, and you can have (as currently #defined) 8 swap partitions,
> you're limited to 16GB swap, which then follows a max of 8GB RAM. We'd like
> to sell servers with 32GB or 64GB RAM to customers who request such for
> their applications. Such customers generally have no problem purchasing
> additional disks to be used for swap, likely on a hardware RAID controller.
dou you actually want to page that high memory? These high memory
configurations are usually used by databases and other huge applications
that have their own memory management.
Other UNIX versions, e.g. the UnixWare with dshm have implemented special
memory pools (in this case dshm) to give unswappable memory to this
applications. While I don't like such implementations with fixed memory
pools it might be a good idea to have a MAP_DEDICATED flags to mmap
(/dev/zero) to allocate non-aged and thus non-paged memory.
To not make the system unusable by allocating too much of this memory
allocation might need a special capability and/or a dynamic limit of
allocatable unaged memory (sysctl?).
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
On Mon, Mar 05, 2001 at 09:58:00AM +0100, Christoph Rohland wrote:
> Hi Matt,
>
> On Sun, 4 Mar 2001, Matt Domsch wrote:
> > My concern is that if there continues to be a 2GB swap
> > partition/file size limitation, and you can have (as currently
> > #defined) 8 swap partitions, you're limited to 16GB swap, which then
> > follows a max of 8GB RAM. We'd like to sell servers with 32GB or
> > 64GB RAM to customers who request such for their applications. Such
> > customers generally have no problem purchasing additional disks to
> > be used for swap, likely on a hardware RAID controller.
>
> I did think about that too and I also think the 2GB limit is not
> appropriate for the big servers. But I do not beleive that you need so
> much swap on these machines. If you drive a 32 GB machine so heavily
> into swap it is more busy finding the pages to swap than doing
> anything really interesting. (At least that's my experience)
While 2.4 did grow the maximum filesizes to CACHEPAGESIZE*2G
bytes by scaling pagecache contained file page offsets with
the CACHEPAGESIZE -- which may or may not be the same as the
machine PAGE_SIZE. It can be larger, though propably not smaller.
For SWAP uses there is also similar 32 bit quantity (actually
it is "unsigned long"), however some bits in the the swp_entry_t
are being used to something usefull in the cache logic besides
of the offset inside the file.
Indeed looking at the source, include/asm-i386/pgtable.h
defines following:
#define SWP_TYPE(x) (((x).val >> 1) & 0x3f)
#define SWP_OFFSET(x) ((x).val >> 8)
#define SWP_ENTRY(type, offset) ((swp_entry_t){ ((type) << 1)|((offset) << 8) })
The i386 actually support up to 4*16 = 64 swap files (or partitions)
with this SWP_TYPE() definition, while include/linux/swap.h does
define MAX_SWAPFILES to be 8 ... If that were a pointer array
to kmalloc()ed blocks, the limit could be much higher. Indeed
I think this is the only *static* limit anywhere in the current
swap code.
Similarly it supports 2^24 PAGES of swap at i386 per file/partition.
( 16 million pages of 4k each = 64 GB -- should be enough ;) )
( That would require vmalloc() to allocate 32 MB block, though.
That might not be possible at every occasion -> swapon may fail. )
The more I read the documentation (= source and its comments),
the more I am inclined to think that the beast *will* work with
swap-partitions (and files!) larger than 2G.
Stephen Tweedie did this 'SWAPSPACE2' work for 2.4 series, what
he might tell ? Is it really just a matter of fixing the
mkswap
utility ? Was Stephen just conservative saying:
"Don't go over 2G" (I haven't tested it)
Reviewing thru the architectural definitions of these SWP_***()
macroes, the shifts used for SWP_OFFSET seem to vary in between
7-12 and for Alpha and MIPS64: 40. Indeed things are not very
easy to understand with 64 bit architectures. It looks like
those architectures use the low 32 bits of swp_entry_t for
something, while most use at most couple of bits.
Oh, even those 64-bit system seem to give at least 24 bits for
PAGE_SIZE 'offset'. The lowest bitcount for 'offset' seems to
be at s390 which gives "only" 2^20 * 4k pages, or 4 GB per
swap file/partition. (SWP_OFFSET() shifts with 12, which is
same as PAGE_SHIFT for the machine. Why SPARC64 uses PAGE_SHIFT
in its own unique way, that I don't know.)
Somehow I suspect that the makers of each architecture port have
not quite understood what the swp_entry_t bits are used for, and
have blindly presumed them to be related to PAGE_SIZE ...
> For 2.5 we could perhaps think about a new swapfile layout which
> allows bigger partitions.
The format seems to be just fine.
> Greetings
> Christoph
/Matti Aarnio
On 5 Mar 2001, Christoph Rohland wrote:
> > We've also seen (anecdotal evidence here) cases where a kernel
> > panics, which we believe may have to do with having 0 < swap < 2x
> > RAM. We're investigating further.
>
> That would be a kernel bug which should be fixed. The kernel should
> handle oom/oos.
There was a bug which made the OOM-killer not work for some
workloads. It should be fixed in the latest -ac kernels...
If in doubt, please test ;)
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
On 5 Mar 2001, Christoph Rohland wrote:
> BTW often these big servers run databases and application servers
> which have most of their memory in shared memory. Shared memory does
> free the swap entries on swapin. (I thought about changing that but as
> long as we have no garbage collection for idle swap entries I will not
> do it)
It's on my infinite TODO list ;)
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
>> For 2.5 we could perhaps think about a new swapfile layout
> The format seems to be just fine.
No, the present definition is terrible.
Read the mkswap source. A forest of #ifdefs,
and still sometimes user assistance is required
because mkswap cannot always figure out what the "pagesize" is.
There are two main problems:
(i) "new" swap is hardly larger than "old" swap
(ii) the unit in which new swap is measured is a mystery
So, the next swap space has (i) a signature "SWAPSPACE3",
(ii) (not strictly necessary) a size given as a 64-bit number in bytes.
Moreover, the swapon call must not refuse swapspaces
that are larger than the kernel can handle.
Andries
William T Wilson wrote:
> On Fri, 2 Mar 2001 [email protected] wrote:
>
> > Linus has spoken, and 2.4.x now requires swap = 2x RAM.
>
> I think I missed this. What possible value does this have? (Not even
> Sun, the original purveyors of the 2x RAM rule, need this any more).
RAM is still about 100x more expensive than HD. So I always recommend
you use about 2% of the money you spent on RAM to pay for the HD space
to handle swap.
Actually the deal is: either use enough swap (about 2x RAM) or use
none at all.
A "good" operating system will want to use say half your memory for
buffers, even if there are processes using that half of your RAM. Not
when they are actively using it, but only after they have NOT used it
for say an hour. Then the users of the machine will see efficient use
of the resources. It does have the disadvantage that when you come back
in the morning, your xterm may have been swapped out because of the
nightly backups and stuff....
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
>>>>> " " == Rogier Wolff <[email protected]> writes:
> William T Wilson wrote:
>> On Fri, 2 Mar 2001 [email protected] wrote:
>>
>> > Linus has spoken, and 2.4.x now requires swap = 2x RAM.
>>
>> I think I missed this. What possible value does this have?
>> (Not even Sun, the original purveyors of the 2x RAM rule, need
>> this any more).
> RAM is still about 100x more expensive than HD. So I always
> recommend you use about 2% of the money you spent on RAM to pay
> for the HD space to handle swap.
> Actually the deal is: either use enough swap (about 2x RAM) or
> use none at all.
I believe the 2xRAM rule comes from the OS's where ram was only buffer
for the swap. So with 1xRAM you had a running system with 1xRAM
memory, so nothing is gained by that much swap.
On Linux any swap adds to the memory pool, so 1xRAM would be
equivalent to 2xRAM with the old old OS's.
Generally I would say that you need so much swap that you mouse does
not stop when its used. That usually means so much swap as you can
read/write within 10-30 seconds when done continuous. If you need more
swap the system becomes unuseable and performance goes realy down.
But thats all just my liking. Some applications can use 10xRAM swap
and still not stop the mouse from working, some applications do that
with 100 MB swap. I would keep swap moderate (one 2GB partition should
be enough for any normal system) and use swapfiles in case more is
needed temporary.
MfG
Goswin
Le 08 Mar 2001 14:05:25 +0100, Goswin Brederlow a ?crit :
> I believe the 2xRAM rule comes from the OS's where ram was only buffer
> for the swap. So with 1xRAM you had a running system with 1xRAM
> memory, so nothing is gained by that much swap.
I think kernels 2.4.x came back to this behavior.
> On Linux any swap adds to the memory pool, so 1xRAM would be
> equivalent to 2xRAM with the old old OS's.
no more true AFAIK
Xav
Xavier Bestel wrote:
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> Le 08 Mar 2001 14:05:25 +0100, Goswin Brederlow a _crit :
>
> > I believe the 2xRAM rule comes from the OS's where ram was only buffer
> > for the swap. So with 1xRAM you had a running system with 1xRAM
> > memory, so nothing is gained by that much swap.
>
> I think kernels 2.4.x came back to this behavior.
>
> > On Linux any swap adds to the memory pool, so 1xRAM would be
> > equivalent to 2xRAM with the old old OS's.
>
> no more true AFAIK
I've always been trying to convice people that 2x RAM remains a good
rule-of-thumb.
Rogier.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
Rogier Wolff wrote:
> > > On Linux any swap adds to the memory pool, so 1xRAM would be
> > > equivalent to 2xRAM with the old old OS's.
> >
> > no more true AFAIK
>
> I've always been trying to convice people that 2x RAM remains a good
> rule-of-thumb.
---
Ug. I like to view swap as "low grade memory" -- i.e. I really
should spend 99.9% of my time in RAM -- if I spill, then it means
I'm running too much/too big for my computer and should get more RAM --
meanwhile, I suffer with performance degradation to remind me I'm really
exceeding my machine's physical memory capacity.
An interesting option (though with less-than-stellar performance
characteristics) would be a dynamically expanding swapfile. If you're
going to be hit with swap penalties, it may be useful to not have to
pre-reserve something you only hit once in a great while.
Definitely only for systems where you don't expect to use swap (but
it could be there for "emergencies" up to some predefined limit or
available disk space).
--
The above thoughts and | They may have nothing to do with
writings are my own. | the opinions of my employer. :-)
L A Walsh | Trust Technology, Core Linux, SGI
[email protected] | Voice: (650) 933-5338
On Fri, 27 Apr 2001, LA Walsh wrote:
> An interesting option (though with less-than-stellar performance
> characteristics) would be a dynamically expanding swapfile. If you're
> going to be hit with swap penalties, it may be useful to not have to
> pre-reserve something you only hit once in a great while.
This makes amazingly little sense since you'd still need to
pre-reserve the disk space the swapfile grows into.
A dynamically growing swap file can only save you if you
reserve enough free space on your filesystem for the thing
to grow...
regards,
Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
Rik van Riel wrote:
>
> On Fri, 27 Apr 2001, LA Walsh wrote:
>
> > An interesting option (though with less-than-stellar performance
> > characteristics) would be a dynamically expanding swapfile. If you're
> > going to be hit with swap penalties, it may be useful to not have to
> > pre-reserve something you only hit once in a great while.
>
> This makes amazingly little sense since you'd still need to
> pre-reserve the disk space the swapfile grows into.
>
> A dynamically growing swap file can only save you if you
> reserve enough free space on your filesystem for the thing
> to grow...
I seams to work for M$, not that they are a good example.
But in /proc/sys/vm or /proc/sys/swapfile having
min_swap, max_swap, min_free_space and the filename to use. This could
then be set by init scripts like sysctl.
It never grows larger than max(swapfile.max_swap, free_space -
min_free_space).
so if you have free space on the filesystem it can be used,
but if you don't have space the current behavior remains.
Sure it would be slow, but that would only be a problem if you
run out of swap space and need to allocate more. Any
time this routine allocates a larger file than syapfile.min_swap
or frees space you send a WARN message.
Now the user will know why the performance dropped
and can either add RAM, or increase swap with by
partition, file, or increase swapfile.min_swap.
Those with enough RAM/swap will never even know it's there.
-Thomas
> I've always been trying to convice people that 2x RAM remains a good
> rule-of-thumb.
IMO this is pointless
total used free shared buffers cached
Mem: 517456 505332 12124 111016 97752 236884
-/+ buffers/cache: 170696 346760
Swap: 131048 23216 107832
Of course for me, I'm not about to waste 1gb of disk space for swap.
The swap I have is 2 partitions, one on each drive both with a priority of
0. Personally, I like the way it's done on my box.
--
Lab tests show that use of micro$oft causes cancer in lab animals
On Fri, 27 Apr 2001, Rik van Riel wrote:
> On Fri, 27 Apr 2001, LA Walsh wrote:
>
> > An interesting option (though with less-than-stellar performance
> > characteristics) would be a dynamically expanding swapfile. If you're
> > going to be hit with swap penalties, it may be useful to not have to
> > pre-reserve something you only hit once in a great while.
>
> This makes amazingly little sense since you'd still need to
> pre-reserve the disk space the swapfile grows into.
It makes roughly the same sense as over-committing memory.
Both are useful, both are unreliable.
Hugh
On Fri, 27 Apr 2001, Hugh Dickins wrote:
> On Fri, 27 Apr 2001, Rik van Riel wrote:
> > On Fri, 27 Apr 2001, LA Walsh wrote:
> >
> > > An interesting option (though with less-than-stellar performance
> > > characteristics) would be a dynamically expanding swapfile. If you're
> > > going to be hit with swap penalties, it may be useful to not have to
> > > pre-reserve something you only hit once in a great while.
> >
> > This makes amazingly little sense since you'd still need to
> > pre-reserve the disk space the swapfile grows into.
>
> It makes roughly the same sense as over-committing memory.
> Both are useful, both are unreliable.
True, agreed.
Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
Rik van Riel wrote:
> On Fri, 27 Apr 2001, LA Walsh wrote:
>
> > An interesting option (though with less-than-stellar performance
> > characteristics) would be a dynamically expanding swapfile. If you're
> > going to be hit with swap penalties, it may be useful to not have to
> > pre-reserve something you only hit once in a great while.
>
> This makes amazingly little sense since you'd still need to
> pre-reserve the disk space the swapfile grows into.
---
Why? Why not have a zero length file that you grow only if you spill?
If you can't spill, you are out of memory -- or reserve a 'safety'
margin ahead -- like reserve 32k at a time and grow it. It may make
little sense, but I believe it is what is used on pseudo OS's
like Windows -- you *can* preallocate, but the normal case has
Windows managing the swap file and growing it as needed up to
available disk space. If it is doable in windows, you'd think there'd
be some way of doing it in Linux, but perhaps linux's complexity
doesn't allow for that type of feature.
As for disk-space reserves, if you have 5% reserved for
root' on a 20G ext disk, that still amounts to 1G reserved for root.
Seems an automatically sizing swap file might be just fine for some people
not me, I don't even like to use swap, but I'm not my mom using windows ME either).
But, conversely, if it's coming out of space I wouldn't normally
use anyway -- say the "5%" -- i.e. the 5% is something I'd likely only
use under *rare* conditions. I might have enough memory and the
right system load that I also 'rarely' use swap -- so not reserving
1G/1G (2xMEM) on my laptop both of which will rarely get used seems like
a waste of 2G. I suppose if I put it that way I might convince myself
to use it,
--
The above thoughts and | They may have nothing to do with
writings are my own. | the opinions of my employer. :-)
L A Walsh | Trust Technology, Core Linux, SGI
[email protected] | Voice: (650) 933-5338
LA Walsh wrote:
> Rogier Wolff wrote:
>
> > > > On Linux any swap adds to the memory pool, so 1xRAM would be
> > > > equivalent to 2xRAM with the old old OS's.
> > >
> > > no more true AFAIK
> >
> > I've always been trying to convice people that 2x RAM remains a good
> > rule-of-thumb.
>
> ---
> Ug. I like to view swap as "low grade memory" -- i.e. I really
> should spend 99.9% of my time in RAM -- if I spill, then it means
> I'm running too much/too big for my computer and should get more RAM --
> meanwhile, I suffer with performance degradation to remind me I'm really
> exceeding my machine's physical memory capacity.
Agreed. However, with current growing memory sizes, people are
suggesting: "I ran with 32Mb RAM and 64Mb swap until a year ago, so
128Mb ram should allow me to run swapless". I disagree.
The price-difference between RAM and disk is such (*) that if you
follow the guideline of swap=2xRAM, you're still spending 20 to 50
times as much on the RAM as you are on the disk space for swap.
Even if the swap is going to be idle 99.9% of the time, the investment
allows you to say "gosh what is the machien slow today. It might be
swapping" instead of "Why the heck has the machine crashed (#) all of
a sudden."
Rogier.
(*) And remains like that!
(#) Even if we have a good OOM killer, you might find the machine in a
non-workable state.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
Wakko Warner wrote:
> > I've always been trying to convice people that 2x RAM remains a good
> > rule-of-thumb.
>
> IMO this is pointless
>
> total used free shared buffers cached
> Mem: 517456 505332 12124 111016 97752 236884
> -/+ buffers/cache: 170696 346760
> Swap: 131048 23216 107832
>
> Of course for me, I'm not about to waste 1gb of disk space for swap.
>
> The swap I have is 2 partitions, one on each drive both with a priority of
> 0. Personally, I like the way it's done on my box.
So you've spent almost $200 for RAM, and refuse to spend $4 for 1Gb of
swap space. Fine with me.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
> So you've spent almost $200 for RAM, and refuse to spend $4 for 1Gb of
> swap space. Fine with me.
I put this much ram into the system to keep from having swap. I still say
swap=2x ram is a stupid idea. I fail to see the logic in that. Disk is
much much slower than ram and if you're writing all ram to disk that's also
slow.
I have a machine with 256mb of ram and no disk. It runs just fine w/o swap.
Only reason I even had swap here is if I ran something that used up all my
memory and it has happened.
Since when has linux started to be like windows "our way or no way"?
--
Lab tests show that use of micro$oft causes cancer in lab animals
Wakko Warner wrote:
> > So you've spent almost $200 for RAM, and refuse to spend $4 for 1Gb of
> > swap space. Fine with me.
> I put this much ram into the system to keep from having swap. I
> still say swap=2x ram is a stupid idea. I fail to see the logic in
> that. Disk is much much slower than ram and if you're writing all
> ram to disk that's also slow.
> I have a machine with 256mb of ram and no disk. It runs just fine
> w/o swap. Only reason I even had swap here is if I ran something
> that used up all my memory and it has happened.
> Since when has linux started to be like windows "our way or no way"?
I've ALWAYS said that it's a rule-of-thumb. This means that if you
have a good argument to do it differently, you should surely do so!
I maintain a 32M machine without swap. My workstation has 768Mb RAM
and almost 2G swap:
/home/wolff> free
total used free shared buffers cached
Mem: 770872 766724 4148 0 259816 78308
-/+ buffers/cache: 428600 342272
Swap: 1843212 1840 1841372
/home/wolff>
That disk space is just sitting there. Never to be used. I spent $400
on the RAM, and I'm now reserving about $8 worth of disk space for
swap. I think that the $8 is well worth it. It keeps my machine
functional a while longer should something go haywire... As I said:
If you don't want to see it that way: Fine with me.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
On 04.28 Rogier Wolff wrote:
>
> I've ALWAYS said that it's a rule-of-thumb. This means that if you
> have a good argument to do it differently, you should surely do so!
>
I'm not so sure it's only a 'rule of thumb'. Do not know the state of
paging in just released 2.4.4, but in previuos kernel, a page that was
paged-out, reserves its place in swap even if it is paged-in again, so
once you have paged-out all your ram at least once, you can't get any
more memory, even if swap is 'empty'.
Now that macs leave out that kind of swap (MacOS classic), linux takes it.
At least macos does not allow you to set vm to less than your physical mem.
--
J.A. Magallon # Let the source
mailto:[email protected] # be with you, Luke...
Linux werewolf 2.4.4 #1 SMP Sat Apr 28 11:45:02 CEST 2001 i686
Rogier Wolff writes:
> Wakko Warner wrote:
>>> So you've spent almost $200 for RAM, and refuse to spend
>>> $4 for 1Gb of swap space. Fine with me.
So that is a factor of 50 in price. It's what, a factor of 1000000
in access time?
> That disk space is just sitting there. Never to be used. I spent $400
> on the RAM, and I'm now reserving about $8 worth of disk space for
> swap. I think that the $8 is well worth it. It keeps my machine
> functional a while longer should something go haywire... As I said:
> If you don't want to see it that way: Fine with me.
It is a disaster waiting to happen. Instead of having the offending
process get killed, your machine could suffer extreme thrashing.
Have enough swap for idle processes and no more.
at the low end useing a bit of disk for swap doesn't hurt, I ran into a
case a couple years ago on AIX systems. we buy them with 2G ram so that we
don't need to swap, but discovered (the hard way) that we also needed to
allocate 4G of disk space for those boxes (allocating less then 2G meant
that we couldn't use the 2G of RAM). This meant that we had to go out and
buy 2nd hard drives for every machine, just to put the swap files on.
now disks are larger today so it's not as much of an issue, but even with
modern 9-18G drives you can end up eating up 20% or more on a large
machine, this starts to be significant. you can try to say that any box
with that much ram must have lots of disk as well, and most of the time
you will be right, but not all the time. there are cases (webservers for
example) where the machines will be built with lots of RAM and CPU and
little disk becouse they get all their content and put all their logs
elsewhere on the network. in fact with the advances in flash size and the
desire to create high performance clusters, I would not be surprised to
see web node machines produced with no hard drives. it means one less
thing that can break on the system (think a rack of transmeta powered
boxes with no moving parts in the rack except possibly fans)
David Lang
On
Sat, 28 Apr 2001 [email protected] wrote:
> Date: Sat, 28 Apr 2001 16:11:47 +0200 (MEST)
> From: [email protected]
> To: Wakko Warner <[email protected]>
> Cc: Rogier Wolff <[email protected]>,
> Xavier Bestel <[email protected]>,
> Goswin Brederlow <[email protected]>,
> William T Wilson <[email protected]>, [email protected],
> [email protected]
> Subject: Re: 2.4 and 2GB swap partition limit
>
> Wakko Warner wrote:
> > > So you've spent almost $200 for RAM, and refuse to spend $4 for 1Gb of
> > > swap space. Fine with me.
>
> > I put this much ram into the system to keep from having swap. I
> > still say swap=2x ram is a stupid idea. I fail to see the logic in
> > that. Disk is much much slower than ram and if you're writing all
> > ram to disk that's also slow.
>
> > I have a machine with 256mb of ram and no disk. It runs just fine
> > w/o swap. Only reason I even had swap here is if I ran something
> > that used up all my memory and it has happened.
>
> > Since when has linux started to be like windows "our way or no way"?
>
> I've ALWAYS said that it's a rule-of-thumb. This means that if you
> have a good argument to do it differently, you should surely do so!
>
> I maintain a 32M machine without swap. My workstation has 768Mb RAM
> and almost 2G swap:
>
> /home/wolff> free
> total used free shared buffers cached
> Mem: 770872 766724 4148 0 259816 78308
> -/+ buffers/cache: 428600 342272
> Swap: 1843212 1840 1841372
> /home/wolff>
>
> That disk space is just sitting there. Never to be used. I spent $400
> on the RAM, and I'm now reserving about $8 worth of disk space for
> swap. I think that the $8 is well worth it. It keeps my machine
> functional a while longer should something go haywire... As I said:
> If you don't want to see it that way: Fine with me.
>
> Roger.
>
>
>
> --
> ** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
> *-- BitWizard writes Linux device drivers for any device you may have! --*
> * There are old pilots, and there are bold pilots.
> * There are also old, bald pilots.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Albert D. Cahalan wrote:
> So that is a factor of 50 in price. It's what, a factor of 1000000
> in access time?
Actually it's only about 100000.
> > That disk space is just sitting there. Never to be used. I spent $400
> > on the RAM, and I'm now reserving about $8 worth of disk space for
> > swap. I think that the $8 is well worth it. It keeps my machine
> > functional a while longer should something go haywire... As I said:
> > If you don't want to see it that way: Fine with me.
>
> It is a disaster waiting to happen. Instead of having the offending
> process get killed, your machine could suffer extreme thrashing.
>
> Have enough swap for idle processes and no more.
Right. Now there is some time where "extreme thrashing" will alert ME
(a human, I think) to try and find/kill the offending process.
Otherwise I have to trust Rik's OOM killer. Now his OOM killer isn't
all that bad. But it isn't human. Humans are better at actually
finding the real CAUSE. An OOM killer might hit one or two innocent
processes along the way. So far I've killed the right process ALL the
time. I can't say the same for the OOM killer.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
David Lang wrote:
> at the low end useing a bit of disk for swap doesn't hurt, I ran into a
> case a couple years ago on AIX systems. we buy them with 2G ram so that we
> don't need to swap, but discovered (the hard way) that we also needed to
> allocate 4G of disk space for those boxes (allocating less then 2G meant
> that we couldn't use the 2G of RAM). This meant that we had to go out and
> buy 2nd hard drives for every machine, just to put the swap files on.
>
> now disks are larger today so it's not as much of an issue, but even with
> modern 9-18G drives you can end up eating up 20% or more on a large
> machine, this starts to be significant. you can try to say that any box
> with that much ram must have lots of disk as well, and most of the time
> you will be right, but not all the time. there are cases (webservers for
> example) where the machines will be built with lots of RAM and CPU and
> little disk becouse they get all their content and put all their logs
> elsewhere on the network. in fact with the advances in flash size and the
> desire to create high performance clusters, I would not be surprised to
> see web node machines produced with no hard drives. it means one less
> thing that can break on the system (think a rack of transmeta powered
> boxes with no moving parts in the rack except possibly fans)
On Sat, 28 Apr 2001 [email protected] wrote:
> > I've ALWAYS said that it's a rule-of-thumb. This means that if you
> > have a good argument to do it differently, you should surely do so!
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
At 2:04 PM -0400 2001-04-28, Albert D. Cahalan wrote:
>It is a disaster waiting to happen. Instead of having the offending
>process get killed, your machine could suffer extreme thrashing.
>
>Have enough swap for idle processes and no more.
Let's altogether now say "working set".
(Does Linux swap out text, by the way, he asks ignorantly?)
--
/Jonathan Lundell.
Jonathan Lundell wrote:
>
> (Does Linux swap out text, by the way, he asks ignorantly?)
.text is just droped and read back from the actuall file it's not put into the swap
On Fri, Apr 27, 2001 at 11:40:40PM +0100, Hugh Dickins wrote:
> > > An interesting option (though with less-than-stellar performance
> > > characteristics) would be a dynamically expanding swapfile. If you're
> > > going to be hit with swap penalties, it may be useful to not have to
> > > pre-reserve something you only hit once in a great while.
> > This makes amazingly little sense since you'd still need to
> > pre-reserve the disk space the swapfile grows into.
> It makes roughly the same sense as over-committing memory.
> Both are useful, both are unreliable.
And we have the one, so we should also implement the other one to
be totally unreliable.
*gd&r*
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< been there and had much fun >>>>>>>>>>>>
> paging in just released 2.4.4, but in previuos kernel, a page that was
> paged-out, reserves its place in swap even if it is paged-in again, so
> once you have paged-out all your ram at least once, you can't get any
> more memory, even if swap is 'empty'.
This is a bug in the 2.4 VM, nothing more or less. It and the horrible bounce
buffer bugs are forcing large machines to remain on 2.2. So it has to get
fixed
Alan
> > The swap I have is 2 partitions, one on each drive both with a priority of
> > 0. Personally, I like the way it's done on my box.
>
> So you've spent almost $200 for RAM, and refuse to spend $4 for 1Gb of
> swap space. Fine with me.
Stupid argument. Very stupid argument. Take a 16Gb server. You now want
to buy 64Gb of hard disk for the swap. Only because of partition limits you'll
beed at least 2 disks entirely dedicated to it, which also means a controller
a larger PSU and a bigger case.
The swap behaviour of 2.4 is a bug.
Kenneth Johansson wrote:
> Jonathan Lundell wrote:
> >
> > (Does Linux swap out text, by the way, he asks ignorantly?)
>
> .text is just droped and read back from the actuall file it's
> not put into the swap
Is this always true, even for init? Can init be swapped out?
In general, is there a safe way to replace executable files for
programs that might be running while their on-disk images are
replaced?
Thanks for any hints...
Torrey Hoffman
[email protected]
On Mon, 30 Apr 2001, Torrey Hoffman wrote:
>
> In general, is there a safe way to replace executable files for
> programs that might be running while their on-disk images are
> replaced?
>
Yes. Perfectly safe:
mv /usr/bin/exeimage /usr/bin/exeimage.sav
cp /wherever/exeimage /usr/bin/exeimage
The executing task will continue to use the old image until it exits.
New tasks will use the new image. You can even replace `mv` and `cp`
this way. It is best to test new programs first, though, so you
know that it's linked with a runtime library that you have on your
system.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
Richard B. Johnson writes:
> On Mon, 30 Apr 2001, Torrey Hoffman wrote:
> > In general, is there a safe way to replace executable files for
> > programs that might be running while their on-disk images are
> > replaced?
>
> Yes. Perfectly safe:
>
> mv /usr/bin/exeimage /usr/bin/exeimage.sav
> cp /wherever/exeimage /usr/bin/exeimage
>
>
> The executing task will continue to use the old image until it exits.
Even more effective is:
mv /wherever/exeimage /usr/bin/exeimage
The kernel keeps around the contents of the old file while
the executing process still runs.
This is also basically how things like libc get installed.
A single mv is not only preserves currently referenced contents,
it is atomic.
Later,
David S. Miller
[email protected]
On Mon, 30 Apr 2001, David S. Miller wrote:
>
> Richard B. Johnson writes:
> > On Mon, 30 Apr 2001, Torrey Hoffman wrote:
> > > In general, is there a safe way to replace executable files for
> > > programs that might be running while their on-disk images are
> > > replaced?
> >
> > Yes. Perfectly safe:
> >
> > mv /usr/bin/exeimage /usr/bin/exeimage.sav
> > cp /wherever/exeimage /usr/bin/exeimage
> >
> >
> > The executing task will continue to use the old image until it exits.
>
> Even more effective is:
>
> mv /wherever/exeimage /usr/bin/exeimage
>
> The kernel keeps around the contents of the old file while
> the executing process still runs.
>
> This is also basically how things like libc get installed.
> A single mv is not only preserves currently referenced contents,
> it is atomic.
>
> Later,
> David S. Miller
> [email protected]
Sure, but now you can't get back if the new software doesn't run.
This is why I recommended the two steps and cautioned about testing
the new stuff first.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
Hi,
On Mon, Apr 30, 2001 at 03:14:25PM -0400, Richard B. Johnson wrote:
> > mv /wherever/exeimage /usr/bin/exeimage
[...]
> > This is also basically how things like libc get installed.
> > A single mv is not only preserves currently referenced contents,
> > it is atomic.
One restriction: /wherever and /usr/bin must be on the same partition,
otherwise the mv will be the same as "rm /usr/bin/exeimage && cp
/wherever/exeimage /usr/bin/exeimage && rm /wherever/exeimage", which
is for sure not atomic.
> Sure, but now you can't get back if the new software doesn't run.
> This is why I recommended the two steps and cautioned about testing
> the new stuff first.
Then create a hardlink first, to keep a backup _and_ atomically
replace the file.
Andreas
--
Build a system that even a fool can use and only a fool will want to use it.