Re: Freeing memory

Hi Nigel, Harald. I'm suffering memory freeing problems/ hibernation 
freezing from 3.3 version. 32 bit /64 bit doesn't matters - tested. One 
machine on 3.2.12 is working fine for 47 days by now. Another with 3.2 tree:

09:45:30 up 68 days, 20:34, 15 users,  load average: 0.18, 0.21, 0.31

TuxOnIce debugging info:
- TuxOnIce core  : 3.2.1
- Kernel Version : 3.2.10-05355-gf5dcb59
- Compiler vers. : 4.4
- Attempt number : 51
- Parameters     : 0 667648 0 0 -2 5
- Overall expected compression percentage: 0.
- Compressor is 'lzo'.
   Compressed 2247098368 bytes into 688314679 (69 percent compression).
- Block I/O active.
   Used 170584 pages from swap on /dev/sda3.
- Max outstanding reads 2901. Max writes 1837.
   Memory_needed: 1024 x (4096 + 368 + 112) = 4685824 bytes.
   Free mem throttle point reached 0.
- Swap Allocator enabled.
   Swap available for image: 753568 pages.
- I/O speed: Write 213 MB/s, Read 280 MB/s.
- Extra pages    : 50 used/2000.
- Result         : Succeeded.

It causes some commit in 3.3 tree, but you know that I think. :(

Milan



On 05/21/2012 08:46 AM, Harald Judt wrote:
> Hi Nigel,
>
> I've updated to current git in the hope the memory freeing problems
> would be solved. Unfortunately, they are still there and I've been
> trying to narrow the issue down. Actually, there are two issues:
>
> First, the memory eating process seems to lock up the machine when it
> requests too much memory. Commmit
> f8262d476823a7ea1eb497ff9676d1eab2393c75 "PM / Hibernate: fix the number
> of pages used for hibernate/thaw buffering" doesn't help with that.
> Maybe tuxonice needs to play catch up on that? Using smaller values and
> more tries seems to help with the freezes, but I don't know what a safe
> value would be.
>
> Next, there seems to be a limit to what amount of the pagecache is
> freeable using the tuxonice memory eater method. Having a total of 16
> GiB, I increased the max tries and set a limit of max 4096MiB to free
> per try so that it would not freeze, but the memory eater hit some limit
> (at that time 4973MiB) where it could not free more memory. Dropping the
> caches manually via "echo 1 > /proc/sys/vm/drop_caches" immediately
> solved the problem and resulted in an image of 2180MiB, IIRC
> image_size_limit was set to 3GiB.
>
> There is an easy way to reproduce this, probably both issues actually:
> Just copy some big files, e.g. videos, before hibernating.
>
> I've also used the shrink_all_memory call instead of the separate
> requests for freeing low and high pages, but that didn't make any
> noticable difference. BTW: That debug message in
> tuxonice_prepare_image.c "Asked shrink_all_memory for ... low pages &
> ... pages from anywhere) is a bit outdated, since shrink_all_memory is
> no longer used.
>
> I believe that memory freeing seemed to work fine before and the culprit
> is some commit between 3.2-rc6 and 3.3. Might it have to do something
> with what f8262d476823a7ea1eb497ff9676d1eab2393c75 tried to fix?
> However, my machines are all 64 bit. Do you have any idea, shall I try
> to bisect?
>
> Harald
>