ubc_overflow

[Francois Rabe]

I have searched, on this site and others with regards to ubc_overflow and have found no information. I have read an article that on GS1280 systems this should be set to 1, on GS80's this should be set to 0 and for any other system this should be -1 (default setting). Can anybody tell me what this does? Is there a performance increase? And where can I find more information on ubc_overflow? It is not in the Tru64 V5.1B documentation.

[Ralf Puchner · Accepted solution]

The ubc_overflow parameter is new to 5.1B PK3, and its default value is -1.

The ubc_overflow parameter needs to be set to 0 for a GS80/160/320 server.

Prior to V5.1B PK #3 (BL24), caching activities for any given file would be constrained solely on a per RAD basis [where the referencing thread was executing]. Under certain load conditions, this would lead to heavy thrashing between files competing for resources. Enabling ubc_overflow tends to reduce the
contention by allowing caching activities to failover to another RAD where resources are more readily available. However, several factors namely: type of access, symmetry of memory resources, remote reference latencies,
and I/O proximities - can signficantly impact overal performance.

On GS320 [and derivative] platforms, testing indicated that enabling ubc_overflow tended to yield a gain when ubc_maxpercent was greater than 40 and file accesses were
generally random.

Therefore, in order to prevent possible system performance degradation, it may be necessary to reset the ubc_overflow parameter
to "0", especially when ubc_maxpercent is set to a low value, or for applications doing a large number of sequential file accesses.

[Joerg Schulenburg]

Ralf,
Is ubc_overflow=-1 on a GS1280 the reason, that borrowed UBC is not freed, if memory pages are needed by other RADs to avoid
low memory condition?
I mentioned that problem on
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=859125
but without any response.
I read that ubc_overflow can be -1, 0 or 1.
You are saying that ubc_overflow can be set or reset. Is 0 resetting? Is 1 setting? What about -1?
Can ubc_overflow set on the running system or do I need to reboot? Is there still no documentation?
Thanks in advance for answers.

[Erich Wimmer]

I don't know if this the reason for your problem.
ubc_overflow is -1 per default. This means, the op.-system itself decides, if ubc_overflow will be used or not depending on hw-architecture and other settings. ubc_overflow can be set dynamically with
"sysconfig -r vm ubc_overflow=x". 0 means no ubc_overflow will be used, 1 means it will be used.
Once can check the actual setting (also if automatically set) by:

kdbx -k /vmunix

(kdbx) px *(struct rad *)rad_ptr[0]
struct {
rad_id = 0x0
rad_state = 0x1
rad_mad = 0xfffffc00023b8000
..
..
(kdbx) px ((struct memory_affinity_domain *)0xfffffc00023b8000).md_ubc.ubc_overflow

Regards, Erich

[Joerg Schulenburg]

Dear Erich,
Thanks for your helpfull explanations.
I tried it, but I got:
kdbx -k /vmunix
dbx version 5.1
Type 'help' for help.

thread 0xfffffc00785b2a80 stopped at [thread_block:3307 ,0xffffffff000ba1f0] Source not available
warning: Files compiled -g3: parameter values probably wrong
(kdbx) px *(struct rad *)rad_ptr[0]
rad_mad = 0xfffffc0013d56000
(kdbx) px ((struct memory_affinity_domain *)0xfffffc0013d56000)\
.md_ubc.ubc_overflow
0x7360e
(kdbx) px ((struct memory_affinity_domain *)0xfffffc0013d56000).md_ubc
struct {
ubc_lru_lock = 0xc0000145002db8f2
ubc_lru = 0xc0000146002dbbb2
...
ubc_borrowlimit = 0x14319
...
ubc_minpages = 0x784df777
ubc_maxpages = 0x0
...
ubc_overflow = 0x7360e

Pointer seem to be shifted somehow.
So did debugging failed because of the kernel patch (T64KIT0025519-V51BB25-20050505)?

Joerg

[Erich Wimmer]

Joerg,
sorry, there have been changes from BL24 to BL25 (patchkit 3 to patchkit 4), I will try to find it out.
Erich