| Author |
Message |
Nick Maclaren
Guest
|
 Posted:
Thu Feb 10, 2005 10:47 pm Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
In article <OBMOd.3366$ng6.2829@newssvr17.news.prodigy.com>,
"mike" <mike@mike.net> writes:
|>
|> I did not realize that MVS and /370 were so efficient at context switching.
|> This is a famous problem with HURD. It sounds like the HURD developers
|> should copy the IBM solution.
Er, no, ABSOLUTELY not. Don't even think of it. Study it, yes;
take good ideas from it, yes; copy it, no. Remember the quote:
From the viewpoint of MVS, it is hard to distinguish MS-DOS
and Unix.
Actually, that is unfair on Unix. Change MS-DOS to Windows NT or
VMS, and it is true and fair.
The basic concepts are so different between MVS and Unix that there
is essentially no chance of copying MVS's solutions. Does HURD
allow even the simple facility of a process X running a completely
unrelated process Y within its address space (and thus being able
to pass structures as arguments)? MVS allowed even the equivalent
of setuid programs to be called that way.
The forms of context switching that was efficient in MVS were that
way partly because they did not do most of what is done by context
switching in Unix. The form that did all that was done in Unix (and
more) ran like a drain in both MVT and MVS/370 - MVS/XA was a bit
better. CICS and GUTS (and to some extent TSO, plus several other
subsystems) were written to bypass MVT/MVS's dire context switching.
|> It would be an interesting research project to look at combining this
|> context switch technology with the 'hypervisor" and LPAR technology on both
|> Z and P hardware to share resources across VM's.
It would be rather like crossing a beetle and a pig - it might end
up with a flying pig, but smart people wouldn't bet that way.
Regards,
Nick Maclaren. |
|
| Back to top |
|
 |
Eric P.
Guest
|
| Posted:
Thu Feb 10, 2005 11:01 pm Post subject:
Re: intel's Vanderpool and virtualization in general (was Re |
|
|
Del Cecchi wrote:
| Quote: |
Eric P. wrote:
Del Cecchi wrote:
If you go wander around IBM's web site, I am confident you will find
plenty of information about the virtues of virtualization. It seems to
be a key element of the Server Value Proposition. Or whatever.
Looking at
http://www-1.ibm.com/servers/eserver/about/virtualization/
it seems to be mostly concerned with systems management,
and remote management in particular.
These are functions I would prefer, and seem most natural,
located in the OS and accessable via APIs and thereby usable for
many purposes by value added and ISV developed applications.
Eric
There are many hits on www.ibm.com when you search for virtualization.
One advantage is that one can run many instances of an operating system
or systems on a single physical box. This allows server consolidation
for example. But if you have a PC/single user mindset then it can be
hard to realize the benefits of virtualization.
|
Yes, and I acknowledge that in mucho buck mid/mainframe systems this
may be useful because you can't just go out and buy another cpu.
But with PC's you can. That is just accepting reality and not,
as you suggest, a PC centric mindset.
However WRT PC's, I do think it is fair to ask just how
much of this is real, useful functionality and understand which
situations it might be beneficial in, verses to what extent
the emperor has dropped his virtualized drawers.
Eric |
|
| Back to top |
|
|
Eric Smith
Guest
|
| Posted:
Fri Feb 11, 2005 8:02 am Post subject:
AMD Pacifica virtualization (was Re: intel's Vanderpool...) |
|
|
Now that Intel has published their Vanderpool specifications, and even
contributed code using it to the Xen virtual machine project, has AMD
published any details of how their Pacifica virtualization support will
work? It would be interesting to contrast them. |
|
| Back to top |
|
|
Guest
|
| Posted:
Fri Feb 11, 2005 5:43 pm Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
"Eric P." <eric_pattison@sympaticoREMOVE.ca> writes:
| Quote: | I would be happy if MS libraries just ported between their own OS
versions. There was no technical reason for dll-hell to occur in the
first place, and I see no reason for it to continue other than
sloven.
|
It is not sloth. Without DLL hell, the upgrade parade would slow and
billy might have to look for a real job.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be. |
|
| Back to top |
|
|
Joe Seigh
Guest
|
| Posted:
Fri Feb 11, 2005 6:59 pm Post subject:
Re: intel's Vanderpool and virtualization in general (was Re |
|
|
On Tue, 08 Feb 2005 22:41:58 +1100, Andrew Reilly <andrew-newspost@areilly.bpc-users.org> wrote:
| Quote: | Also notwithstanding that there's an obvious pre-existing example of
wholesale virtualization in the IBM mainframes, is there actually a really
good reason to use virtualization on a day-to-day basis, or is it just a
practical acknowledement that there are failings of the OSes that are used
on these things?
I mean, OSes are supposed to be there to ration access to a machine's
hardware resources, for the benefits of the (several) applications that
want to share it.
What do virtualizers provide that couldn't be incorporated into an OS?
|
Allegedly, one of the things you are supposedly going to be able to do
with Cell processors is job out programming tasks to other Cell processors
in the network. If you are going to do that then you want a really good
sandbox. There's lot's of sandboxing stuff out there, Java's JVM, chroot
jails on unix, etc... but IBM's vm technology is orders of magnitude better
and more secure than any of those. If IBM's virtualization is built-in as
part of the firmware, then you have something that's of known quality and
security, vs. trying to judge how good the sandbox for whatever OS you're
running on the Cell processor at the time.
--
Joe Seigh
Lock-free synchronization primitives
http://atomic-ptr-plus.sourceforge.net/ |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
| Posted:
Fri Feb 11, 2005 10:47 pm Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
| Quote: | Er, no, ABSOLUTELY not. Don't even think of it. Study it, yes;
take good ideas from it, yes; copy it, no. Remember the quote:
|
the context change is with respect to permissions, address space,
registers, etc. not with respect to execution resource control. this
is analogous to some of the GNOSIS stuff ... which turned into
keykos. at one point keykos people made some mention that they could
do (some kinds of?) transactions more efficiently than TPF
(transaction processing facility kernel that is used by airline res
and financial transaction systems ... and grew out of the old airline
control program).
going back to OS/360 they have a really heavy weight dispatching unit
with task control block (TCB). lots of online and transactions systems
would create a large subsystem under OS/360 and then implement their
own internal dispatching & scheduling (to avoid the really heavy
weight operation of the main dispatcher); things like cics, ims, atm
transaction stuff, etc.
somewhere along the way, SRBs were created for MVS (basically a light
weight kernel threaded mechanism ... my vague recollection was that
STL & IMS group were heavily involved in the SRB stuff).
however, the mainframe hardware program call stuff is a mechanism that
is analogous to an application making an internal call to a subroutine
library ... that just happens to be in another virtual address space
(and doesn't require kernel checking about resource allocation, etc).
The execution of the subroutine library then has (slightly elevated)
privileges to address back into the calling application's address
space.
various past gnosis/keykos postings.
http://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001n.html#10 TSS/360
http://www.garlic.com/~lynn/2002f.html#59 Blade architectures
http://www.garlic.com/~lynn/2002g.html#0 Blade architectures
http://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
http://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#75 30th b'day
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
http://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
http://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
http://www.garlic.com/~lynn/2003j.html#20 A Dark Day
http://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
http://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
http://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts
http://www.garlic.com/~lynn/2003m.html#24 Intel iAPX 432
http://www.garlic.com/~lynn/2003m.html#54 Thoughts on Utility Computing?
http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
http://www.garlic.com/~lynn/2004e.html#27 NSF interest in Multics security
http://www.garlic.com/~lynn/2004m.html#29 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#49 EAL5
http://www.garlic.com/~lynn/2004n.html#41 Multi-processor timing issue
http://www.garlic.com/~lynn/2004o.html#33 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2004p.html#23 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005.html#7 How do you say "gnus"?
http://www.garlic.com/~lynn/2005b.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#7 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005b.html#12 [Lit.] Buffer overruns
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ |
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Fri Feb 11, 2005 11:09 pm Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
In article <m3oeerc7jq.fsf@lhwlinux.garlic.com>,
Anne & Lynn Wheeler <lynn@garlic.com> writes:
|> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
|> > Er, no, ABSOLUTELY not. Don't even think of it. Study it, yes;
|> > take good ideas from it, yes; copy it, no. Remember the quote:
|>
|> the context change is with respect to permissions, address space,
|> registers, etc. not with respect to execution resource control. ...
Quite. In the Unix design, those are intimately connected and
the security depends to a large part on them not being separated.
It would be possible, in Unix, for one process to transfer data
over a pipe/socket, put itself to sleep and start the other process,
all without going through the dispatcher, but that still wouldn't
be the same.
What Unix really COULD do with is a lightweight threading mechanism
that would enable that for threads within a single process. But it
isn't possible to get there starting from POSIX.
|> however, the mainframe hardware program call stuff is a mechanism that
|> is analogous to an application making an internal call to a subroutine
|> library ... that just happens to be in another virtual address space
|> (and doesn't require kernel checking about resource allocation, etc).
|> The execution of the subroutine library then has (slightly elevated)
|> privileges to address back into the calling application's address
|> space.
Yes. I was referring to the earlier and cruder forms, where it
was (marginally) possible to mix privileged and unprivileged units
in the same address space. Now, THOSE techniques are best left to
decay where they lie - the mechanisms you are referring to are a
LOT cleaner.
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
Anne & Lynn Wheeler
Guest
|
| Posted:
Sat Feb 12, 2005 12:34 am Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
| Quote: | What Unix really COULD do with is a lightweight threading mechanism
that would enable that for threads within a single process. But it
isn't possible to get there starting from POSIX.
|
darn, you beat me to it ... i wanted to post that ..
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ |
|
| Back to top |
|
|
Joe Seigh
Guest
|
| Posted:
Sat Feb 12, 2005 2:05 am Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
On 11 Feb 2005 18:09:15 GMT, Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
| Quote: |
In article <m3oeerc7jq.fsf@lhwlinux.garlic.com>,
Anne & Lynn Wheeler <lynn@garlic.com> writes:
|> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
|> > Er, no, ABSOLUTELY not. Don't even think of it. Study it, yes;
|> > take good ideas from it, yes; copy it, no. Remember the quote:
|
|> the context change is with respect to permissions, address space,
|> registers, etc. not with respect to execution resource control. ...
Quite. In the Unix design, those are intimately connected and
the security depends to a large part on them not being separated.
It would be possible, in Unix, for one process to transfer data
over a pipe/socket, put itself to sleep and start the other process,
all without going through the dispatcher, but that still wouldn't
be the same.
What Unix really COULD do with is a lightweight threading mechanism
that would enable that for threads within a single process. But it
isn't possible to get there starting from POSIX.
|
That's what I thought Solaris door calls were until I figured out what
they really were. That they were just slightly enhanced unix domain
sockets was a bit of a let down.
Joe Seigh
Lock-free synchronization primitives
http://atomic-ptr-plus.sourceforge.net/ |
|
| Back to top |
|
|
myren, lord
Guest
|
| Posted:
Sat Feb 12, 2005 2:21 am Post subject:
Re: Cell press release, redacted. |
|
|
are they planning on stappling on a graphics card somewhere, or are the
SPE's all the heavy vector procssors we should expect from the ps3?
iirc, nvidia was onboard the video side of the ps3 somewhere. it'll be
interesting to see if theres a conventional (or even an interesting)
shader pipeline at the end of the cell pipe.
seems like we're only talking about 1/2 to 2/3 the picture, at least
when regarding whats initially going to be a gaming device.
as a last stray comment, it'll be interesting to see how STI justifies
the ex-orbital costs of a Cell based workstation when they're selling
PS3's for $300 - $400. particularly given the distributed basis
underlying cell: right now it seems like price is the only way to keep
people from just buying more and more ps3's.
Myren |
|
| Back to top |
|
|
Morten Reistad
Guest
|
| Posted:
Sat Feb 12, 2005 3:00 pm Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
In article <opsl1wv7rtqm36vk@grunion>, Joe Seigh <jseigh_01@xemaps.com> wrote:
| Quote: | On 11 Feb 2005 18:09:15 GMT, Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
In article <m3oeerc7jq.fsf@lhwlinux.garlic.com>,
Anne & Lynn Wheeler <lynn@garlic.com> writes:
|> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
|> > Er, no, ABSOLUTELY not. Don't even think of it. Study it, yes;
|> > take good ideas from it, yes; copy it, no. Remember the quote:
|
|> the context change is with respect to permissions, address space,
|> registers, etc. not with respect to execution resource control. ...
Quite. In the Unix design, those are intimately connected and
the security depends to a large part on them not being separated.
It would be possible, in Unix, for one process to transfer data
over a pipe/socket, put itself to sleep and start the other process,
all without going through the dispatcher, but that still wouldn't
be the same.
What Unix really COULD do with is a lightweight threading mechanism
that would enable that for threads within a single process. But it
isn't possible to get there starting from POSIX.
That's what I thought Solaris door calls were until I figured out what
they really were. That they were just slightly enhanced unix domain
sockets was a bit of a let down.
|
I keep reading specs around threading and posix etc.
Is there really anything barring a split of the fork() call, a.la.
tops20; (separate handling of thread and address space) and to
reimplement fork() in top of that?
i.e.
pid_t fork(void )
{
pid_t proc;
proc = new_thread();
if (proc != 0) return proc; /* errors and parent stop here */
if (new_moby()) {
exit(-1);
}
return 0;
}
-- mrr |
|
| Back to top |
|
|
Nick Maclaren
Guest
|
| Posted:
Sat Feb 12, 2005 4:31 pm Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
In article <2kikuc.bq81.ln@via.reistad.priv.no>,
Morten Reistad <firstname@lastname.pr1v.n0> wrote:
| Quote: |
I keep reading specs around threading and posix etc.
Is there really anything barring a split of the fork() call, a.la.
tops20; (separate handling of thread and address space) and to
reimplement fork() in top of that?
|
No, but that's irrelevant. The issues that I am referring to are
logically twofold:
POSIX defines so much state that must be maintained for each
thread separately that a thread is very little 'lighter' than a
process sharing the address space. And that is how most Unices
implement them.
The scheduling model is based on the transparent, process level
Unix one and is totally inappropriate for tightly coupled threaded
code. That is why many (or most?) OpenMP implementations use their
own scheduling, based on spin loops, and not POSIX threads'.
The data consistence model is also a problem, but not relevant to
this thread.
Regards,
Nick Maclaren. |
|
| Back to top |
|
|
Casper H.S. Dik
Guest
|
| Posted:
Sat Feb 12, 2005 8:30 pm Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
| Quote: | POSIX defines so much state that must be maintained for each
thread separately that a thread is very little 'lighter' than a
process sharing the address space. And that is how most Unices
implement them.
The scheduling model is based on the transparent, process level
Unix one and is totally inappropriate for tightly coupled threaded
code. That is why many (or most?) OpenMP implementations use their
own scheduling, based on spin loops, and not POSIX threads'.
The data consistence model is also a problem, but not relevant to
this thread.
|
That's just typical; data consistency is always seen as a problem
for "the other threads" :-)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth. |
|
| Back to top |
|
|
Joe Seigh
Guest
|
| Posted:
Sat Feb 12, 2005 9:07 pm Post subject:
Re: intel's Vanderpool and virtualization in general |
|
|
On 12 Feb 2005 11:31:48 GMT, Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
| Quote: | In article <2kikuc.bq81.ln@via.reistad.priv.no>,
Morten Reistad <firstname@lastname.pr1v.n0> wrote:
I keep reading specs around threading and posix etc.
Is there really anything barring a split of the fork() call, a.la.
tops20; (separate handling of thread and address space) and to
reimplement fork() in top of that?
No, but that's irrelevant. The issues that I am referring to are
logically twofold:
POSIX defines so much state that must be maintained for each
thread separately that a thread is very little 'lighter' than a
process sharing the address space. And that is how most Unices
implement them.
|
I'm not sure that's entirely true. It may seem that way, given most
implementations. Theoretically, given an ideal hw and kernel architecture
you should be able to get really light weight thread implementations.
| Quote: |
The scheduling model is based on the transparent, process level
Unix one and is totally inappropriate for tightly coupled threaded
code. That is why many (or most?) OpenMP implementations use their
own scheduling, based on spin loops, and not POSIX threads'.
|
Barrier synchronization is really suboptimal. But when someone is
fixated on using a particular synchronization construct, it is a waste
of breath trying to convince them otherwise.
--
Joe Seigh
Lock-free synchronization primitives
http://atomic-ptr-plus.sourceforge.net/ |
|
| Back to top |
|
|
George Neuner
Guest
|
| Posted:
Tue Feb 15, 2005 6:02 am Post subject:
Re: intel's Vanderpool and virtualization in general (was Re |
|
|
On Wed, 09 Feb 2005 13:18:30 -0500, "Eric P."
<eric_pattison@sympaticoREMOVE.ca> wrote:
| Quote: | Anton Rang wrote:
Well, some customers have needs (or at least a desire) for:
(a) Running more than one OS, or more than one version of the OS,
on the same hardware. Maybe you have software that requires
Windows 98 or Solaris 6. No need to keep a separate box for
this one application. This also works for software which
wants to be installed in a particular location.
Similar to (a), this makes sense if there is a constraint on
getting e new machine. At $1000/box vs $1500/staff-day you don't
need too much futzing about with co-resident OS installs and
virtual device configuration to eat up all your savings.
(d) Isolating customers from each other. The typical OS can
do this for ordinary users, but not administrators. ...
That isolation should definitely be in an OS. If it isn't then I
would consider it an OS design failure and best addressed there.
Doing otherwise strikes me as fixing the symptom not the problem.
It seems to come down to cpu cost. In days of yor, on pricey
cpus VM made sense. But in a < $1000/PC universe
I don't see the justification outside of niche situations.
Buying a new box seems the path of least resistance and
most effective use of peoples time.
|
But may not be the most effective use of resources. Some years ago, I
can remember laughing at a comparison drawn between the resources used
in the web server farms run by Microsoft and IBM. At the time of the
comparison Microsoft's site used hundreds of 4-cpu Wintel boxes and
employed dozens of people to adminster them, while IBM's site used a
couple of mainframes (forget which model) and a half dozen people.
There was a recent article, I think it was in InformationWeek, about
chronic under utilization of systems and the drain the "one app, one
server" approach imposes on IT budgets and personnel. The article
cited a number of reasons for why the approach is so prevalent, but
the number one reason given was lack of software stability, both in
the operating systems and the major applications in dominent use -
instability which makes it impractical to share hardware among
multiple applications. The result is proliferation of boxes that sit
idle much of the time.
George
--
for email reply remove "/" from address |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in