Re: Teraspace memory allocation

[David & Eileen Keck <bstars@xxxxxxxxxxxxx>]

Simon,
    The focus of my model, lets call it a Teraspace Server (TP), was to show
that Teraspace can be shared across multiple jobs.  It was not an
application specific solution.  You say such a server would be self
defeating.  I think that like any other design component, it depends on the
application.  Suppose the application needs to process thousands of data
structures, each of  which are 100K in size, in a compute intensive manner.
Also, assume that other jobs need to do the same, sharing the changing data
in the shared teraspace data stuctures.  The TP is no longer self defeating
... it's a champ (like Kordell Stewart !!).  You also say the TP would run
into space issues, while I would say it's application dependent.

In the second paragraph below, you say I must pass data with the handle, and
that this will cause the design to hit the 16MB limit.  I say the amount of
data to be passed with the handle depends on the application.  For example,
the input to a chess application may be a single move, such as d2d4.  The
chess engine would not need to return a hash table, or all intermediate
results, though it may use a teraspace for such a hash table.  It just needs
to return a 4 byte move in response.

If the main driver of the TP is RPG IV, then the handle / teraspace address
x-ref could be stored and managed in a 16MB based data structure (the offset
being the handle).  Since each handle could uniquely refer to a large
portion of the TP, the 16 MB limit being exceeed is not a mathematical
certainty, but rather a function of the application which would have to be
assessed.   -Dave K.

You wrote:
---snip-----
> It would certainly be possible to have a TS server as you describe but
> then a number of jobs would be sharing a single TS which sort of defeats
> the point of using them.  Such a server would certainly allow larger
> storage allocations than the various HEAP strategies but you would
> eventually run into space issues.
>
> Since one process cannot directly address TS allocated in another process
> (unless you use the shm* APIs to specifically allocate shared TS) you
> cannot pass the addresses around.  Therefore you must pass a handle which
> will require the TS server to manage updating the data in the storage
> associated with the handle, therefore you must pass the data along with
> the handle.  You will soon run into the 16MB limit which would negate any
> benefit gained from a TS server.  If you concerned by the 16MB limit then
> why would you bother with TS in the first place?
---snip---