Path: utzoo!yunexus!hydroesm!jtsv16!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!rutgers!mcnc!brooking
From: brooking@mcnc.org (Jim Brooking)
Newsgroups: comp.unix.cray
Subject: Re: How to use an SSD?
Summary: Cray UNICOS SSD Use
Message-ID: <6631@alvin.mcnc.org>
Date: 29 May 90 14:01:04 GMT
Article-I.D.: alvin.6631
References: <1019@orange19.qtp.ufl.edu>
Organization: MCNC; RTP, NC
Lines: 66

(Qualifier: Responding person is only a manager....)

In article <1019@orange19.qtp.ufl.edu>, bernhold@qtp.ufl.edu (David E. Bernholdt) writes:

...
> How are SSDs presently used (under UNICOS)?

On our Y-MP8/432, SSD is used as a cache for disks. On my previous
X-MP/28, it was part cache, part user-accessible as a disk.

> It seems from the routines listed in the man pages that "extended main
> memory" is the way to think of an SSD if one wishes to program for it
> explicitly. From the article, though, they seem to be using a fast
> disk model for it.  So how *do* you actually think of it?

My understanding is that it is a disk, if the site chooses to allow
users at it in that way.
> 
> Does anyone actually explicitly code for an SSD?  Is it worth it? 

Yes, again, if the site allows it, one can explicitly code for an SSD.
However, it's probably easiest if the user thinks of SSD as a disk, and
just does I/O to it. This, in turn, is easiest if one already has a
program that uses one, or a few, small scratch files that will fit
in SSD. These programs will shine on a user-accessible SSD. But will
sink on a non-SSD machine.

> Is explicitly coding for the SSD more or less efficient for the
> particular program than letting the OS use the SSD as it wants?  How
> about for the overall system performance (i.e. what is best in the
> eyes of the people who own the Cray vs. what is best for a user who
> just wants his program to run as-fast-as-possible for the least cost)?

This is an application-dependent question. From my (Comp. Center
Manager) viewpoint, I'd rather have the SSD managed by "us" rather than
the users because, in general, we can probably do it better. (Flame
away...) Most of the applications I've seen do almost as well using SSD
as a (center-managed) disk cache rather than a user-managed file system.
There are significant exceptions, however. For example, a program that
does heavy random access of a file can take a significant performance
hit if the file is cached. My advice, then, is let the Center manage SSD
as a cache, but *make* the Center be alert for cases where cache doesn't
work.

Another point is that I've never seen any convincing evidence that a
particular cache setup was effective. Crayons have accurately pointed
out that "cache is operating with around 95% hit rate". This indicates
to me that there is ample SSD allocated to caching. But if one reduced
the available-to-cache SSD space by, say, 20%, would we still get 95%
hit rates? If we removed some file systems from caching, would we still
get 95%? If we put a portion of the SSD into the hands of some carefully
chosen users, would that be a better use of it? Noone knows (maybe the
Shadow knows...). Cray documentation of ldcache (what they call the SSD
cache facility) typically tells you how to invoke ldcache ("you"=the
system programmer) but but how or why, or how to tell when you got it
right. Or wrong.
> 
> Thanks in advance for helping satisfy my curiosity...

I hope so. Lots of opportunity for research with the SSD, tho.



-- 
>8-}     >:-)     %\(     8^)     :+/     |'[     ;-)     :-O     B^\    :-)
Jim Brooking........North Carolina Supercomputing Center.......(919)248-1145