The following message is a courtesy copy of an article
that has been posted to alt.folklore.computers as well.
[EMAIL PROTECTED] writes:
> Could you translate into layman's terms? What exactly is "server
> virtualization software"?
>
> The concept of "virtual storage", as I understand it, is making an
> application program think it had more core ('RAM') memory than it had
> by using disk storage for parts of a program not being used at that
> moment. It's power was limited as trying to compress too much of a
> program slowed it down significantly. To me, today the concept is
> almost obsolete since RAM memory is damn cheap, measured in many
> hundreds of meagabytes. Virtual was developed when memory was still
> in kilobytes or at best a few megabytes.
>
> Anyway, I don't see how the above definition applies today to
> something like Oracle.
>
> How does this new product make it easier and more efficient for data
> processing centers?
>
> Thanks.
re:
http://www.garlic.com/~lynn/2007s.html#26 Oracle Introduces Oracle VM As It
Leaps Into Virtualization
http://www.garlic.com/~lynn/2007s.html#27 Oracle Introduces Oracle VM As It
Leaps Into Virtualization
http://www.garlic.com/~lynn/2007s.html#35 Oracle Introduces Oracle VM As It
Leaps Into Virtualization
for some topic drift and x-over with this thread
http://www.garlic.com/~lynn/2007s.html#33 Age of IBM VM
Endicott was working on the follow-on to 135/145 ... virgil/tully ...
which had spare room for microcode. There was starting to be mid-range
clone processor competition (primarily outside the US) and was looking
for new added value features ... in addition to simply better
price/performance. They had done a VS1 (kernel) microcode assist and
approached the VM group out in burlington about doing a VM370 microcode
assist.
The VM group turned them down, saying that they were too busy doing
other stuff. As a result, they eventually showed up on my doorstep. Old
post with some results into initial investigation into selecting
portions of vm kernel to "drop" into mcode:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
In addition to the other stuff I was doing in the same timeframe, not
only did i get roped into working on design for ECPS VM microcode assist
... Endicott then wanted me to run around the world with them to explain
what it all met to the business and forcasting people in different
countries around the world. unlike domestic/US, world trade countries
would forcast sales for the upcoming year ... which then turned into
build orders at manufacturing plants ... which were then
bought/delivered to the countries ... which in turn had to be sold to
customers (by contrast, domestic forcasts were not directly tied to
actual sales volume ... so manufacturing plant sites had to do
significant amount of investigation regarding US forcasts since the
plant sites would have to "eat" any inaccuracies).
It turns out that 138/148 (virgil/tully) was just on the leading edge of
shift from hardware costs dominating customer budgets to change-over to
people costs starting to dominate (and skill availability representing
bottleneck to customer installs). As a result, Endicott pushed hard for
having VM370 preinstalled and transparently integrated into every
138/148 shipped from the factory (slightly akin to LPARS in the current
generation of mainframes). The problem was that large portions of the
corporation viewed vm370 as "competitive" with other operating system
offerings and for one reason or another were out to kill the product.
Having vm370 preinstalled and transparently integrated into every
138/148 shipped ran counter to this other political forces (for instance
POK was in the process of making the case for killing off vm370 and
having all the people in the burlington mall group transferred to pok as
part of helping mvs/xa schedules). In any case, the vm370 preinstall
and transparently integrated for every 138/148 was shot down.
As i've posted before, the mid-range product sales really accelerated
with the 138/148 followin ... 43xx machines (as well as vax machines).
past posts mentioning the departmental server phenonama for 43xx (and
vax) machines (43xx had some edge over vax with some large commercial
customers placing 43xx machine orders in multiples of hundreds). a few
recent posts
http://www.garlic.com/~lynn/2007b.html#51 Special characters in passwords was
Re: RACF - Password rules
http://www.garlic.com/~lynn/2007j.html#7 Newbie question on table design
http://www.garlic.com/~lynn/2007m.html#72 The Development of the Vital IBM PC
in Spite of the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007n.html#18 The Development of the Vital IBM PC
in Spite of the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007n.html#20 The Development of the Vital IBM PC
in Spite of the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007n.html#21 The Development of the Vital IBM PC
in Spite of the Corporate Culture of IBM
http://www.garlic.com/~lynn/2007o.html#10 IBM 8000 series
http://www.garlic.com/~lynn/2007o.html#56 360/30 memory
http://www.garlic.com/~lynn/2007r.html#15 The history of Structure capabilities
this market segment then started transition to workstations and large
PCs ... so that the 4331/4341 followons, 4361/4381 never saw the success
of its predecessor (vax sales saw similar effect)
for other topic drift, another group wanted to do vm370-only, 5-way smp
also approached me about the same time ... so i was doing a lot of work
on that project at the same time I was doing the endicott ecps related
stuff (and all the other kernel modifications and enhancements mentioned
in the previous post, including leading up to the releasing the source
manager). the 5-way smp project eventually got canceled before shipping
misc. past
posts about the http://www.garlic.com/~lynn/subtopic.html#bounce
the 5-way smp project included significant microcode capability ... so
i moved a lot of i/o scheduling, dispatching, and other kernel
operations into the microcode as defined functions (different approach
than ecps which was moving very targeted short snipets of kernel code
into microcode). the i/o scheduling has some characteristics of what was
later seen in 370/xa ... and the dispatching bore some resumblance to
the later work done in i432 (making management and number of processors
somewhat transparent to the kernel code). all of these functions could
execute concurrently on different processors.
after 5-way project was killed, a quick&dirty version was adapted to
vanilla vm370 kernel running on standard 370 multiprocessors (w/o all
the microcode capability). This involved about 6000 bytes of kernel code
that would execute concurrently with fine-grain locking on multiple
different processors. However, the majority of the kernel smp support
was done with traditional single kernel lock that was state-of-the-art
in the period.
The were some differences, i.e that standard single kernel lock (of the
period) was used for all of the kernel, and processors on entry to the
kernel would "spin" on the lock until it was made available (effectively
the kernel would only be executing on single processor at a time).
The adaption of the VAMPS design had fine-grain locking multiprocessing
changes for only (very) small portion of the kernel that represented the
majority of time spent in the kernel. I didn't have to make go thru the
rest of the kernel making multiprocessors changes ... since it continued
to run on only one processor at a time (with single kernel lock). I
contended it provided nearly the thruput of having completely modified
the whole kernel for fine-grain lock and parallelism ... while requiring
a small fraction of the source code changes.
The other difference was that there was a extremely light-weight queuing
mechanism ... instead of single kernel "spin-lock" (for the majority of
the kernel code) ... it was something that I originally called a
"bounce" lock ... i.e. an attempt was made to obtain the kernel lock,
and the processor couldn't obtain the lock, it would queue a request
(for the kernel lock) and go off to the dispatcher to look for other
kinds of work.
Some of the kernel restructuring in preperation for this kind
of multiprocessor support ... was what was included in the
resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
... as mentioned in
http://www.garlic.com/~lynn/2007s.html#33 Age of IBM VM
and created a dilemma when it was decided to release standard product
multiprocessor support (the resource manager was "unbundled" and charged
for ... while the multiprocessor support was to ship as bundled/free).
http://www.garlic.com/~lynn/subtopic.html#unbundle
