Lazy swap allocation for 32-bit processes?

[Jerry Whelan]

The man page for chatr says that +dz will enable lazy swap allocation for 64-bit binaries.
I've got some systems where we've got 32-bit processes that allocate 10x the amount of memory that they actually use. The net effect is that with 4GB of physical RAM, I need close to 20GB of swap space, yet that swap is never used, just reserved - I'm throwing away more than a whole 18GB disk on each box.

Fixing the code to not allocate all that memory is not an option, nor is going to 64-bit binaries an option either. I'd like to reclaim my wasted disks, does anyone know of a way to enable lazy swap allocation for 32-bit processes? The chatr command does not complain when I apply +dz to the binary, and I looked at the SOM header definitions and there is a field to indicate lazy swap - it just doesn't seem to do anything.

[CHRIS_ANORUO]

You don't ned that amount of swap space for your system.
enable psuedo swap and allocate swap space at swapon
allocate_fs_swapmap=0
swapmem_on=1
shmem=1
Increase your shmmax to 1Gb
Look for recent patches or the latest support plus cd.


cheers

[Andy Monks]

Jerry,

Yep, lazy swap does work with 32bit apps.

See 'Lazy Swap' in /usr/share/doc/11.00RelNotes

[Jerry Whelan]

I read those notes, they are kind of ambiguous.
I've got test code that when compiled 64-bit and modified with
"chatr +z enable" will allocate 40GB without any problem,
but when compiled 32-bit and also modified with "chatr +z enable"
will only give me 800MB (the approximate vmlimit on my C3600).

Here's the code if anyone wants to try for themselves:

#include

#define CHUNKSIZ (1024*1024*200)
#define MAXKIDS 200

main()
{
int pids[MAXKIDS],
i;
char *ptr;

ptr = (char *) malloc(CHUNKSIZ);

for(i=0; i < MAXKIDS; i++) {
pids[i] = fork();

if(-1 == pids[i]) { // Can't fork
i--;
break;
}

if(0 == pids[i]) { // Child
sleep(1000);
exit(0);
}

// Parent

fprintf(stderr, "%d ", i);
}

fprintf(stderr, "Did %d procs, that's %d MB, cleaning up...n",
i, i * (CHUNKSIZ / (1024*1024)));
for(;i >= 0; i--)
kill(pids[i], 9);

fprintf(stderr, "Bye, byen");
exit(0);
}

[Andy Monks]

Keith, this is weird,

I ran your program on a machine I've got access to. It's got 514GB of memory and 7GB of swap, giving me a total of 7543MB.

So I ran your program as a normal user and got :-

./lazy
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 Did 72 procs, that's 14400 MB,
cleaningup...
Bye, bye

So, mine stopped at 72 processes. Which is correct due to maxuprc being 75.

So, I then ran it as root (as that does have a process limit) and got :-

# ./lazy
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 8
3 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 10
7 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 12
7 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 14
7 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 16
7 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 Di
d 186 procs, that's 37200 MB, cleaningup...
Bye, bye

The only thing I can think of is it's patch related (which wouldn't surprise me).

We can always compare patches if it helps.

Andy