UBC pages problem

[JTWang]

When we use DD to backup the raw device data to AdvFS file domain, our memory is almst used to zero by UBC buffer. I don't know whether there is a shell command to release the UBC pages.

[Ralf Puchner]

no the memory is allocated dynamically depending on the settings of your kernel configuation, why not lower the ubc_maxpercent parameter?

Now we start guessing the version of your os ;-)

[Hein van den Heuvel]

"I don't know whether there is a shell command to release the UBC pages."

What good would that do?
The damage (if any) is already done.

All you would do is release potentially usefull data by emptyness. And if anything, you'd tell the system to flush out what little older, more usefull usefulldata might be left, because that dd stuff is recent and will be removed last.

"our memory is almst used to zero by UBC buffer. "

And what is the problem with that?

Now I admit that is is unlikely you'll see a quick re-use of the dd data stream, and while filling up it may well have pushed out what was really more valuable (but the system can not look in the future!).

But, to anwer your question check out: sysconfig -q vm | grep ubc

To release the ubc memory (assuming a relatively decend Tru64 version) just temporarely set ubc_max way down, and back up again a little later.

To prevent 'bad citizen' from poluting the cache with large amounts of read-once data, verify settings (and definitions!) for specifically vm_ubcseqstartpercent, vm_ubcseqpercent but check the rest too.

Good luck!
Hein.

[Joerg Schulenburg]

I also not understand, why ubc should be a problem.
Nobody here mentioned ubc_borrowpercent, but this is the important kernel parameter.

Man page tells:
Percentage of memory above which the UBC is only borrowing memory from
the virtual memory subsystem. Paging does not occur until the UBC has
returned all its borrowed pages.

If ubc_borrowpercent is minimum (ubc_minpercent=0) ubc can treated like free memory. Unfortunatly I get other results
if I test it with dd and a simple memeater.
Borrowed UBC is not freed, instead UBC tries to grow on low memory condition (how its defined exactly?) and paging
happens. Whether I am completely wrong or system is buggy. No other operating system I know behaves like Tru64 (*sigh*).

[Hein van den Heuvel]

[ Ah, looks like this topic is still being monitored by the author.]

Did lowering ubc-max not do the job?
(I guess not, considering the '1 point' :-)

Supposedly dd-ing a raw device into a file (through compress I hope!) creates v ery large single files.

Tru64 will aggressively try to cache those, but that is possibly (probably!) a waste of time and memory.

Did you since check out your settings for vm - vm_ubcseqstartpercent and vm - vm_ubcseqpercent as requested?
Check with: sysconfig -q vm | grep seq
For definitions check: man sys_attrs_vm

With the large default ubc-max those defaults are big (50%, 10%). You may want to trim those way down on your system.

For further help, please specify the OS version/patch level.
Also, please indicate why you think 'releasing ubc pages' is goodness.
And... consider a 'memeater' program like Joerg mentions to force out pages.
Just malloc a bunch and touch each page in a loop. I'll inluce a silly version below that uses shmget instead of malloc (in case you have gh to deal with).

hth,
Hein

#include
#include
#include
#include

main(int argc,char *argv[])
{
int shmid, stat=0, size, stride;
char *maddr, *px;
char usage[] = "Usage: %s MB [command like sleep or ipcs -m] \n";

if (argc < 2) printf(usage, argv[0]), (void) exit(1);

size = 1024*1024*atoi(argv[1]);
shmid = shmget( IPC_PRIVATE, size, 0);
maddr = shmat (shmid, 0, 0);
printf ("shm id = %d, address= %ld %lX\n", shmid, maddr, maddr);
if ((int) maddr != -1) {
stride = getpagesize();
for ( px = maddr; px < (maddr + size); px += stride ) {
*(int *) px = 0;
}
if (argc > 2) system (argv[2]);
printf ("Deleting %d.\n", shmid);
stat = shmctl(shmid, IPC_RMID, NULL);
}
return (stat);
}

[Joerg Schulenburg]

Hi JTWang,

If you still monitor this forum, can you tell us, what the "problem" is?
Is it just the fact that top shows you that
no memory is left, or did you got performance problems (I mean paging, growing swap etc.).
Especially if you have the second case it
would be very helpful for me to know about.

Regards.