[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-desktop
Subject:    Re: [gentoo-desktop] Re: Swap thrashing, autotune swappiness, wrong
From:       Tom Hudak <tom () 1337consulting ! net>
Date:       2004-08-31 21:13:31
Message-ID: 4134E9FB.5030002 () 1337consulting ! net
[Download RAW message or body]

Hmm.. Sounds like all the more reason to finally move to Opterons.
The problem with swap thrashing seems to have gone away in the -ck5 
patch in that I haven't noticed it during successive kernel/package 
compiles as I had in -ck4 and I seem to recall a bit of discussion about 
the vm.mapper initial values and the autotune algorithm changing 
slightly from ck4 to ck5 so maybe Con was sick of all the "My swap is 
thrashing!" e-mails and tweaked things a bit. My personal preference for 
things like that (specifically vm autotuning, automation in general) is 
that it's all well and good to plan something for autonomy, but manual 
control must still be available should your autonomous "foo" go haywire.

That said the ipod also seems to be quite happy in -ck5 so this is 
probably where I'll stay.  I am curious about the 1Gb lowmem patch 
though so I don't have to have the highmem kernel options and take the 
theoretical performance hit however with dual-channel ddr400 I don't 
think it will be perceptible if not barely measurable.

If I see these issue come back I'll probably just go swapless until I 
run into a good reason not to..

-Tom
Duncan wrote:

>Tom Hudak posted <4134A224.4020202@1337consulting.net>, excerpted below,
>on Tue, 31 Aug 2004 11:07:00 -0500:
>
>  
>
>>I can watch my swap drive get absolutely flooded with swap requests and
>>my swap drive starts to fill which should absolutely not happen with 1gb
>>of ram @ ~230M used. The effect of this is an incredible slowdown of
>>what should be a rather speedy machine to the point of unuseably slow.
>>    
>>
>
>Here, also with a gig of RAM (but on AMD64), I decided I didn't need swap
>at all (if I did it was probably due to a memory leak that would quickly
>eat up any swap I had anyway, so what was the use?) and deactivated that
>kernel option. The interesting thing is that recompiling the same kernel
>in the previously compiled kernel tree usually recompiles only one or two
>little items when an option is changed, but THAT one apparently has its
>fingers in virtually EVERYTHING, as it caused almost the entire kernel to
>be recompiled, after changing it.  As I said, I found that rather
>interesting, and believe all those places that changed must be running
>that much more efficiently, now that they don't have to worry about all
>that swap management code.
>
>Do note, however, that it isn't quite as simple as that.  AMD64 has a
>flat memory architecture, with few memory "zones".  x86 is considerably
>more complicated as it has various memory zones to manage memory within 32
>bits, particularly if you have a gig or more of memory.  I'm not sure of
>the details, but apparently, the kernel doesn't have a direct way to move
>memory between the various zones.  Thus, if something in one zone needs to
>be moved to another, it has to be moved out to swap, and then into the
>other zone.  Because it can't be done directly and relies on swap, that
>/does/ put a bit of a kink in the flexibility of your memory  layout.  How
>much that affects you probably depends on what you are running.
>
>FWIW, I've read there's a similar problem with AMD64, altho it's not
>related to quite the same thing.  However, that doesn't hit until the 4
>gig mark, so I don't have to worry about it with only a gig of memory.  By
>the time I can afford four gig, the problem should be fixed.  
>
>Both sets of problems should be fixed eventually, and may be fixed
>already in the latest kernels.  They were discussed earlier this year (I
>originally read about them in LWN kernel coverage of that discussion), and
>the problems have been tackled, but the fix looked to be complex and
>potentially subject to new bugs, so it'll take some time for testing even
>after introduction, particularly the x86 side, as all those memory zones
>complicates things substantially.  Thankfully, AMD64 is just that, a
>64-bit arch, and those zones have been flattened out into a flat memory
>model.  As I said, it's problems were similar but different, and without
>the direct zones problem, easier to handle.
>
>Anyway, if you don't know of anything you do that would require more than
>your gig of real memory, and haven't tried running without swap, it's
>worth the try.  It's gone well here, tho as I said "here" is a bit
>different than x86.
>
>  
>


--
gentoo-desktop@gentoo.org mailing list

[prev in list] [next in list] [prev in thread] [next in thread]