Operating System - Tru64 Unix
1748263 Members
3635 Online
108760 Solutions
New Discussion юеВ

Re: Why is available swap 10% when free swap is 65%

 
SOLVED
Go to solution
Alexey Borchev
Regular Advisor

Re: Why is available swap 10% when free swap is 65%

>> usable memory in deferred mode is physical memory + swap.

- Little correction:
Imho, if a process was swapeed out, then read back into memory - it uses both mem and swap.
The fire follows shedule...
Joerg Schulenburg
Frequent Advisor

Re: Why is available swap 10% when free swap is 65%

>> Imho, if a process was swapped out, then read back into memory - it uses both mem and swap.

Is that in general? I mean for all Unixes or is it a Tru64 "feature"?
On Linux I think pages are read in from swap
and swap can be freed if that pages keep in memory, so that other pages can use this swap space. Doing so only a small part of pages
exist in memory and swap at the same time.
But I am not sure.
If I find some time I will start a test linux
in the qemu PC emulator and test it.
After that I can give a more qualified statement.
Fighting for a better world with more penguins.
Joerg Schulenburg
Frequent Advisor

Re: Why is available swap 10% when free swap is 65%

Ok, I found time to test swap. Its swap+memory
which is usable. I tested IRIX64 and Linux (k2.6.11), lazy type swap of course.

swaptest.c:
main(){ char *buf;int j,i=0;for(;;){
buf=(char *)malloc(1024*1024); /* alloc memory */
if (buf) { i++; for (j=0;j<1024;j++) buf[j*1024]=i; } /* access pages */
else { sleep(1); }
printf(" %dMB\n",i);
}}

Knoppix-3.8 + 512MB memory + 256MB swap

swaptest killed by the kernel at
473MB (without swap) and 728MB (active swap).
I tested also a SGI-O2100-IRIX6.5-64bit
where it was killed after 14GB (10GB memory +
5GB swap). On a SunOS-5.7 machine malloc failed after 1459MB (728MB memory + 1GB swap).
Nothing is crashed, but it was a
very slow on the IRIX machine.
I cant test it on Tru64 because
I dont have a empty machine in lazy mode at the moment and I dont know if it can be tested with a emulator like qemu.
I am interested, if you can make a test. I can do it on the next crash or
if HP support forces me to reboot again.

So the normal result is memory + swap as
usable memory on a good unix.

May be someone can test it for Windows too?
Fighting for a better world with more penguins.
Ralf Puchner
Honored Contributor

Re: Why is available swap 10% when free swap is 65%

I'm not sure why you are testing the program on different platforms and compare the results. Each unix implementation differs from other depending on the base (BSD/SYSV). Windows swapping is totally different, linux is only "unix" like and depending on the distribution will follow an other path.

Tru64 offers 2 swapping modes, if reading the admin guide you will get an explanation.
Modes:

1. total memory = swap
2. total memory = physical memory + swap

So depending on the needs of your application and the vendor config guides choose one of the two modes!
Help() { FirstReadManual(urgently); Go_to_it;; }
Joerg Schulenburg
Frequent Advisor

Re: Why is available swap 10% when free swap is 65%

>> I'm not sure why you are testing the program on different platforms and compare the results.

It was only to show that Tru64 is the only one, which comes with an eager mode and it
would probably be a good idea to remove that mode from the kernel code.
Lazy mode is clearly the better one, therefore people do switch to this mode.
Kernel (and documentation) would be less complex without eager mode.
I would not weep if eager mode is vanished
from the Unix world.

>> ... if reading the admin guide you will get ...
>> 1. total memory = swap
>> 2. total memory = physical memory + swap

Thanks for reading the tuning guide for us.
Assuming the tuning guide is up to date,
we see that Alexeys "Little correction"
has to be corrected.
Fighting for a better world with more penguins.
Alexey Borchev
Regular Advisor

Re: Why is available swap 10% when free swap is 65%

Probably I was unclear with my 'little correction'
To make experimental conformation or rebtion, we should:
- Hawe a Tru64, with lazy swap mode, for example 1 GB ram + 2 GB Swap.
- Hawe two test processes:
1) 'Workhorse' - it consumes, say, 1/2 of Phys. memory, then wait until 'Run' command. Upon command it reads\writes all the mem and wait again.
2) 'Memeater' - exactly Your swaptest.

Now, the experiment:
1) On idle system, run 'Workhorse'. It will have it's 0.5G mem, and will rezide in phys. mem. Passive state - waiting.
Phys Mem usage = 0.5.GB (workhorse)
Swap Usage = 0
2) Start memeater, let it eat 1 GB.
Phys. mem = 1 GB (eater rezide here)
Swap usage = 0.5 GB (Workhorse swapped out)
3) Memeater is treminated or killed.
Phys. mem ~ 0 GB (of course, not 0, because of Tru64 itself)
Swap usage = 0.5 GB (Workhorse still here)
4) Run Workhorse. It will go through it's mem. Tru64 will read workhorse back into memory.

5a) End state 1 - swap space is de-allocated upon read-in:
Phys Mem usage = 0.5 GB (workhorse)
Swap Usage = 0

5b) OR end state 2 - swap space is still allocated upon read-in:
Phys Mem usage = 0.5 GB (workhorse)
Swap Usage = 0.5 (swap-space allocated for workhorse, as in immediate mode)

My 'little correction' is 5b. I.e. imho, Tru 64 will not de-allocate swap.

Your volutes, please - 5a or 5b?

P.S.
By the way, this scenario DOES occur in 'real life'.
The fire follows shedule...
Joerg Schulenburg
Frequent Advisor

Re: Why is available swap 10% when free swap is 65%

Alexey,
I could not test your suggestion on Tru64, because I can not disturb users just for playing with swap. Also Tru64 does not like such kind of experiments on NUMA machines.
But I did it with linux and the outcome should be very similar. I used knoppix-3.8 within qemu and 256M RAM. But I translate the outcome to your 1GB sample for simplicity.
I used the memeater as workhouse too and
used kill -SIGSTOP and -SIGCONT to switch between waiting and running state.

experiment:
1) workhouse stopped, mem=0.5GB, swap=0
2) eater, mem=1GB, swap=0.5GB
3) eater killed, mem~0, swap=0.5GB
4) cont workhouse, mem=0.5GB
as you predicted.

End state is 2, but not exactly as you described!
5b) mem=0.5GB, swap~0.5GB

This is not like in immediate mode.
In immediate mode this part of swap belongs
to workhouse. In our case it can be used
by other process pages. Try additional memeater 1GB run and stop it: mem=1GB, swap=~0.7GB, workhouse runs.
Swap was not reserved for workhouse!
So its simply kind of definition. If the system would show swap=0 it would be also
ok. In both cases (5a and 5b) we dont need disk operations to put workhouse back to swap.
In both cases this part of swap can be reused
by other pages. Thats completly different from immediate mode.
Of course Tru64 can behave different.
The result would be the same,

maxmem=swap+phys.mem.

The difference would
be, that workhouse has to be swapped out
on the next low memory+rest_of_swap condition, whereas
linux can decide to swap other pages out.
Performance would differ and dead locks
are more likely.

Right?

Ralf, what does Tru64 in that experiment?

Happy swapping!
Fighting for a better world with more penguins.