lkml.org 
[lkml]   [2009]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Linux 2.6.31 - very swap-happy with plenty of free RAM
From
On Thu, Nov 19, 2009 at 1:43 AM, Tomasz Chmielewski <mangoo@wpkg.org> wrote:

> What is also interesting, that a normal software RAID-1 sync (i.e. from a
> degraded state) does not seem to make any visible effect on system
> responsiveness.
>
> Uncompress a big tar file, or VM writes out lots of data - system becomes
> really unresponsive.

Setup:

XFS -> LV -> md0 (degraded) -> ST3500630AS ver 3.AA (500gb)
Basically no other disk activity while doing these tests.

barriers on:
$ time git checkout -f
Checking out files: 100% (29108/29108), done.

real 2m51.913s
user 0m3.128s
sys 0m3.004s
$ time rm -r *

real 1m52.562s
user 0m0.072s
sys 0m2.980s
$ sudo mount /usr/src -o remount,nobarrier
$ time git checkout -f
Checking out files: 100% (29108/29108), done.

real 0m9.782s
user 0m2.944s
sys 0m2.984s
$ time rm -r *

real 0m24.996s
user 0m0.076s
sys 0m2.808s

So XFS + barriers are part of the culprit here, but I was only using
xfs for /usr/src. Reformatted that to ext4 after I found that little
nugget of joy. Ext4+barriers isn't anywhere near as dramatic a hit,
it's a much more reasonable speed/safety tradeoff. Again, that's
only for /usr/src, the rest of my system is using ext4, so it doesn't
explain any other workload problems. btrfs doesn't seem to have much
of a hit at all using barriers but I'd need to test that properly,
it's below 6 seconds for checkout and the differences would be in the
noise without averaging multiple runs.

On Thu, Nov 19, 2009 at 9:36 AM, KOSAKI Motohiro
<kosaki.motohiro@gmail.com> wrote:
> Hi Dan,
>
> Umm, very strange.
> I made two debug patch. can you please apply it and post following
> command output?
>
> % cat /proc/meminfo
> % cat /proc/vmstat
> % cat /proc/zoneinfo
> # cat /proc/filecache | sort -nr -k3 |head -30

Unfortunately not, it doesn't compile on 2.6.31 which means I'd have
to re-port vmware & fglrx just to test that.

CC fs/proc/filecache.o
fs/proc/filecache.c: In function ‘iwin_fill’:
fs/proc/filecache.c:108: error: ‘bdi_lock’ undeclared (first use in
this function)
fs/proc/filecache.c:108: error: (Each undeclared identifier is
reported only once
fs/proc/filecache.c:108: error: for each function it appears in.)
fs/proc/filecache.c:109: error: ‘struct backing_dev_info’ has no
member named ‘bdi_list’
fs/proc/filecache.c:109: warning: type defaults to ‘int’ in
declaration of ‘__mptr’
fs/proc/filecache.c:109: error: ‘bdi_list’ undeclared (first use in
this function)
fs/proc/filecache.c:109: error: ‘struct backing_dev_info’ has no
member named ‘bdi_list’
fs/proc/filecache.c:109: error: ‘struct backing_dev_info’ has no
member named ‘bdi_list’

And I can't forward port the patch without major work, since the whole
bdi_writeback structure was introduced post 2.6.31. The recent-rotated
patch works, I'll include that data as soon as I get the memory
pressure back up.

Right now it's behaving correctly after the reboot - the usual sign of
a problem is free memory going way up while swapping like mad. I'm
putting a lot of memory pressure on the kernel post-reboot but swap is
behaving normally. I hope this doesn't take multiple days of uptime
to get back into that state.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-23 22:59    [W:0.087 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site