Swap problem in dsl-2.0


Forum: User Feedback
Topic: Swap problem in dsl-2.0
started by: WDef

Posted by WDef on Dec. 02 2005,08:24
I happen to have a ~600MB swap partition on my hd that I don't need for dsl since I have 1GB ram; dsl finds and enables it unless I boot with 'noswap'.

In dsl-1.5 toram it didn't matter whether this swap was on or off - it never got utilized anyway as there was plenty of ram.  So I forgot about it.

On dsl-2.0 toram, when copying the source tarball for dsl-2.0 (36.9mb) from my pendrive to /home/dsl with emelfm, at first nothing happened, though the copy seemed to be very slow.  Then the center of the emelfm display vanished (as if something was hanging) and the yellow swap use bar on the dock app shot up to 642560 and stayed there after the copy had finished (for the first time  - it's always been zero).

# vmstat -s
     1033364  total memory
     1020040  used memory
      478892  active memory
      468976  inactive memory
       13324  free memory
        3916  buffer memory
      555164  swap cache
      642560  total swap
      388688  used swap <--*
      253872  free swap
       46187 non-nice user cpu ticks
           0 nice user cpu ticks
        7028 system cpu ticks
      315833 idle cpu ticks
           0 IO-wait cpu ticks
      627920 pages paged in
      421423 pages paged out
           2 pages swapped in
           0 pages swapped out
      494433 interrupts
     3081695 CPU context switches
  1133531356 boot time
        4292 forks

Doing

# swapoff -a
# swapon -a

frees up the swap again (back to 0 *) as follows:

#vmstat -s

     1033364  total memory
     1018628  used memory
      476488  active memory
      467636  inactive memory
       14736  free memory
        3916  buffer memory
      939852  swap cache
      642560  total swap
           0  used swap <--*
      642560  free swap
       57010 non-nice user cpu ticks
           0 nice user cpu ticks
        8127 system cpu ticks
      499082 idle cpu ticks
           0 IO-wait cpu ticks
      628860 pages paged in
      421483 pages paged out
           3 pages swapped in
           0 pages swapped out
      719936 interrupts
     3825471 CPU context switches
  1133531356 boot time
        4297 forks

While I can always keep the swap off, I don't think swap should be getting utilized for a file copy onto my ramdisk when I have 1GB ram.  Some extensions are loaded during boot but none of these caused this before.

Posted by WDef on Dec. 02 2005,09:50
Never mind.  On rebooting, this issue seems to have gone away (good).  Something to do with transitioning from 1.5 to 2.0.  Mystery.
Posted by WDef on Dec. 02 2005,14:28
I spoke too soon.  It hasn't gone away.  Much more swap than ram is still being utilized for largish file copies.
Posted by mikshaw on Dec. 02 2005,14:46
DSL now utilizes a portion of a swap partition (if available) to add to its ramdisk.  This is to prevent or postpone problems resulting in the ramdisk filling up.  So copying large files into /home/dsl would affect both ram and swap.

I think this was in 1.5 too, so maybe that's not the issue  ???

Posted by cbagger01 on Dec. 03 2005,04:58
Hmm...

Seems like the solution is to boot with

dsl toram noswap

if you don't want to use the swap.

Posted by WDef on Dec. 05 2005,06:49
For the moment I've shredded the swap partition.  But this is a workaround not a solution.

Thanks Mik - I know about the Friedgold hack increasing the size of the ramdisk to take in swapspace (not in dsl-1.5), but should a 36MB file write to /home/dsl be allowed to spill onto the swap "portion" of the ramdisk when there's 1GB of ram (still 497904 ram free).  Also data appears to be getting swapped out in huge amounts as a result of this file copy (*much* bigger than the 36MB file).    

ie shouldn't it ideally be such that the ram part of the ramdisk gets filled with a new file write before utilising swap-ramdisk.  File copies (incl extension loadings I imagine) appear to be using swap when there is no need.  Presumably also happening on systems with much less ram.

Posted by mikshaw on Dec. 05 2005,15:20
From the way I understand it the ramdisk is created from a portition of ram + a portion of swap.  You get a fixed-sized ramdisk as a result, with the rest of your ram being left alone to be used as ram in the typical manner.  If /home is mounted in /ramdisk, you have a fixed amount of physical ram available for it...when that part of ram is filled it has to move to swap.  This may not be fact, but it's just the way it appears to me.

You can use the df command to see how much of /ramdisk is available.

Posted by WDef on Dec. 10 2005,13:35
I think I'd prefer to see friedgold's hack enabled only by a boot option eg for low ram users.   Easy enough to do, just an "if checkbootparam..." etc around it in knoppix-autoconfig

Just my opinion.

Posted by cbagger01 on Dec. 10 2005,21:14
friedgold's hack should be able to be turned into a boot option, or at the very least, it could be ON by default and then DISABLED via a boot option.

However, I am still curious to know why booting with an existing option like

dsl noswap

does not work?

Posted by WDef on Dec. 15 2005,10:31
Perhaps one thing I didn't make clear is that, once swap gets filled during the large file copy, the copying process slows right down and so do subsequent file copies.  noswap stops this behaviour (didn't I say that? - no matter) - ramdisk obviously can't be remounted at a larger size including the size of swap if there's no swap.

But what of users with +++ram, who try dsl and find their existing swap being used, but don't know about noswap or the expanded ramdisk, and then find some file copying grinds to a near halt?

This caters for low ram users, who are a significant segment (but not all) of dsl users, and by all accounts this is very helpful indeed to them, so they need to be able to at very least switch it on.

The question I'm raising is: I'm not convinced this behavior should be on by default when, as time goes by, more users are bound to have adequate amounts of ram, and therefore not need this hack, which does seem to exact a performance penalty in the case I described?

Posted by sarah on Dec. 15 2005,14:47
Quote (WDef @ Dec. 15 2005,18:31)
This caters for low ram users, who are a significant segment (but not all) of dsl users, and by all accounts this is very helpful indeed to them, so they need to be able to at very least switch it on.

The question I'm raising is: I'm not convinced this behavior should be on by default when, as time goes by, more users are bound to have adequate amounts of ram, and therefore not need this hack, which does seem to exact a performance penalty in the case I described?

::Starting kind of tangential response::

I know this sounds like a strange question, but if a person has a reasonably well "endowed" machine, why would the average person choose DSL over one of the "flashier" Linux distrobutions (including Knoppix)? (Especially over those distrobutions with budget allocations for marketing...)

As an observation (and I will state up front that I have not been observing all that long!) there seems to be quite a few of DSL's users who are either fairly comfortable in Linux, or newbies with older -or just old- machines. In the former case, they are likely to be able to understand to use boot-time switches, and in the latter case, it's going to matter if their machine crashes because it's not well spec'ed and not using all the available resources. They (the people falling into the latter group) might not perceive it as a machine problem (ie a lack of hardware resources) if Win 95/98 ran "just fine" and DSL is supposed to be able to run on a machine with similar specifications to theirs.

As time goes by, it is also possible that there may be more people falling into the "inheritance group" - people who can't afford to buy a new machine and have to rely on what's been donated to them, or even those who have older hardware and can't justify an upgrade to support a new OS (I'm actually thinking of the pre-release suggested specifications for certain propriety OSs here..) and so are considering a switch to something less resource intensive. Of course there are other reasons, and I've just taken those as examples.

I haven't encountered your problem myself WDef, but you asked why the behaviour should be left on by default?
In response I ask if you were able to get your machine to run well enough that you could hook up to the Internet and come here and ask for a solution to your problem? I'm going to assume that you were. What happens if you were not able to get the system up and running well enough to come and  ask for help? As someone new to  DSL (and Linux too), I would not have known the commands to produce what you gave as supporting information in the search for a solution in your first post.

I realise some people might take my response the wrong way and that it's quite a bit off the original topic. But I've posted because the  question was raised by the original poster and largely because I'm curious about the replies (no flames please ;o) ).

I guess what I was wondering was why an option that enables  versatility and usefulness across a large range of machines should be switched off by default for the sake of performance on a percentage (even if it is on a growing number of machines)? I mean the question with sincerity and respect, and hope you won't mind answering so I (and others) can learn :o)

Cheers and beers,
Sarah

Posted by Norm Pierce on Feb. 10 2006,22:41
Potential data loss hazard

John and Robert,

       I recently acquired DSL 2.0 and am quite happy with it.  However, I wanted to alert you to a potential hazard that you may or may not be aware of.

       When booting, I noticed that DSL found three swap partitions on my hard drive.  This was of some concern to me since I only had two swap partitions.

       The other partition that DSL thought was "swap" actually had Red Hat 7.1 installed on it, "had" being the correct tense.  Before I booted DSL it had it, now it doesn't.  Luckily, this is a machine that I use for testing stuff anyway, so in my case nothing was lost that a reinstall won't take care of.  But since other folks may not be so lucky, you will probably want to look into this problem.

       Apparently I must have previously used that partition as a swap partition, and the Red Hat installation didn't overwrite the "SWAP-SPACE" signature.

       Knoppix 4.0.2 did not mistake this partition for a swap partition.

       What's happening in DSL is that /etc/fstab is being generated incorrectly.  This is because /usr/sbin/rebuildfstab uses /usr/sbin/scanpartitions to identify the partitions, which, in turn, depends upon /usr/bin/file to identify them correctly.  In this case it does not (because it sees the old "SWAP-SPACE" signature).

       (Naturally, I will manually remove the "SWAP-SPACE" signature before using this partition again, which will solve my problem.  But I assume you will want to take steps to prevent this from happening to anyone else.)

       I see that Knoppix 4.0.2 has a newer version of scanpartitions, which calls a new utility: /usr/sbin/fstype. When /usr/bin/file says that a partition is a swap partition, that is taken as a suggestion, not a fact, and fdisk is called for a second opinion, which it gives after looking at the actual partition table.  Needless to say, this is a much safer way than depending solely upon the "magic" of /usr/bin/file to get it right.

       I hope this information is helpful.  And thanks for providing the world with DSL -- mostly I like it!

                               Sincerely,
                               Norm Pierce

Powered by Ikonboard 3.1.2a
Ikonboard © 2001 Jarvis Entertainment Group, Inc.