| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reduce the run time of the cache tests.
Description:
Some of the cache tests run for quite a while, which has been
causing problems with our daily build and test. In my last
modification to cache.c, I added code to skip these stress
tests unless we were building in production mode. Since
things go faster in production mode, the extra tests are not
a major problem here.
However, this means that the stress tests are only run once
or twice a week.
Solution:
To try to deal with this, I modified the four longest tests
to throttle depending on whether NDEBUG is defined. When
NDEBUG is not defined, runtime for the cache tests should
be about 1/5th its regular run time. We will see if this
is enough of a reduction to avoid problems.
There is some doubt in my mind as to just how much good the
throttled tests do, but they should be better than nothing.
As mentioned before, the correct solution is to build some
proper, random test code.
Platforms tested:
h5committested
production and debug builds on heping.
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Provide facilities in cache to allow us to avoid a potential cache
consistency bug in the parallel case.
2) Clean up a off by one sanity checking bug.
3) Turn off execution of long running tests in debug mode.
Description:
1) In the parallel case, all writes to metadata must be collective,
but reads may not be. In pricipal, this allows us to different
contents in different caches. This isn't a problem as long as the
correct data is always on disk, but unless we can force certain
writes immediately, that need not be the case.
2) & 3) should need no further explanation.
Solution:
1) Add code allowing us to mark cache entries, and then force
these entries to be flushed at a later time.
Note that to actually avoid the bug, we will have to modify
existing code to use these new features.
2) & 3) should need no further explanation.
Platforms tested:
heping (serial debug and production)
committest (copper, sol, and heping). test failed on heping in the
c++ portion of the build, but at Quincey's siggestion, I am proceeding
with the checkin.
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reduce run time of daily tests.
Description:
cache, the test program for the metadata cache has been taking a while
to execute.
Solution:
As a short term "fix", I have commented out all but one of the long
running test functions. Of course that means that we aren't running
these tests at present. I'm not sure that this is a good idea.
Platforms tested:
Serial on Heping.
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Code cleanup
Description:
Convert chunk iteration code to use skip lists instead of threaded, balanced
binary trees.
Platforms tested:
FreeBSD 4.10 (sleipnir) w/parallel & szip
Too minor to require h5committest
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug Fix/Code Cleanup/Doc Cleanup/Optimization/Branch Sync :-)
Description:
Generally speaking, this is the "signed->unsigned" change to selections.
However, in the process of merging code back, things got stickier and stickier
until I ended up doing a big "sync the two branches up" operation. So... I
brought back all the "infrastructure" fixes from the development branch to the
release branch (which I think were actually making some improvement in
performance) as well as fixed several bugs which had been fixed in one branch,
but not the other.
I've also tagged the repository before making this checkin with the label
"before_signed_unsigned_changes".
Platforms tested:
FreeBSD 4.10 (sleipnir) w/parallel & fphdf5
FreeBSD 4.10 (sleipnir) w/threadsafe
FreeBSD 4.10 (sleipnir) w/backward compatibility
Solaris 2.7 (arabica) w/"purify options"
Solaris 2.8 (sol) w/FORTRAN & C++
AIX 5.x (copper) w/parallel & FORTRAN
IRIX64 6.5 (modi4) w/FORTRAN
Linux 2.4 (heping) w/FORTRAN & C++
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modify the cache code (H5C) to support automatic cache resizing to
adapt to the work load at run time.
Description:
Different applications require different sized caches to maintain
an acceptable hit rate. This set of changes attempts to provide the
ability to adjust to circumstances automatically.
Solution:
Added highly configurable code to allow the user to either set a
fixed cache size, or allow the cache to grow and shrink according to
conditions.
If enabled, cache size increases are triggered when the hit rate
drops below a user specified threshold in a user specified interval.
Cache size reductions (if enabled) are triggered when either the
hit rate exceeds some user specified threshold over a user specified
interval, when the cache contains "enough" entries that haven't been
accessed for a user specified interval, or some mix of the above.
See the header comments on the H5C_auto_size_ctl_t structure in
H5Cprivate.h for further details.
At present, the cache resize configuration options are not
accessible via the user API. Must add this.
Platforms tested:
h5committested, heping (serial), and copper (parallel)
Misc. update:
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code cleanup
Description:
Clean up a bunch of warnings and bring new code better inline with current
library coding practice.
Platforms tested:
FreeBSD 4.10 (sleipnir) w/parallel
Too minor to require h5committest
Misc. update:
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Code cleanup
Description:
Fix problems when compiling with C++ compiler.
Also clean up some warnings with gcc 3.4.x
Platforms tested:
FreeBSD 4.10 (sleipnir)
Too minor to require h5committest
|
|
|
performance.
Description:
Replaced the old metadata cache with a cache with a modified LRU
replacement policy. This should improve the hit rate.
Solution:
Since we want to flush cache entries in increasing address order, I
used the threaded binary B-tree code to store the cache entries.
There is a fair bit of overhead here, so we may want to consider
other options.
While the code is designed to allow the support of other replacement
algorithms, at present, only a modified version of LRU is supported.
The modified LRU algorithm requires that a user selectable portion
of the cache entries be clean. The clean entries are evicted first
when writes are not permitted. If the pool of clean entries is used
up, the cache grows beyond its user specified maximum size. The
cache can also exceed its maximum size if the combined size of the
protected (or locked) entries exceeds the maximum size of the cache.
Platforms tested:
eirene (serial, parallel, fp), h5committested
Misc. update:
|
