Jonathan -
A friend forwarded your posting of 20 Jun to linux-kernel and cap-talk
that mentioned in passing the overhead of transactions in VINO. I'm not
sure how you got your VINO transaction overhead cost of 100x "per kernel
operation".
The last time I measured the transaction system (for my thesis), I saw
overheads of 15.7 microseconds for a transaction begin/end pair, on a
100MHz Pentium, cold-cache (expected-time) numbers. With a 10 ns clock,
this means 1570 cycles; I don't have a number handy for a typical
kernel operation. If you want to consider an L4 IPC a typical kernel
operation, then a transaction begin/end is about one order of magnitude
slower than an IPC (about 100 cycles on an x86, right?).
In our paper at the 2nd OSDI I believe that the transaction overhead
was about 4x the numbers I present here, which I still don't see as
100x difference.
As an aside, I don't understand your statement 1(b) below; given that
transactions (at least as classically defined) are isolated from each
other, a failure of process P1 should have no effect on process P2 if
they are running in separate transactions.
Your suggestion 2 below reminds me of the convolutions that the distributed
systems folk go through. (Read anything about CATOCS lately?)
I realize that this is orthogonal to transparent persistence, which I'd
be happy to argue about with you (any time you're willing to buy the beer).
As I'm not a subscriber to linux-kernel or cap-talk, could you please
cc me on any followup to this discussion?
- Chris
>> From: shapj@us.ibm.com
>> To: alan@lxorguk.ukuu.org.uk
>> cc: linux-kernel@vger.rutgers.edu, cap-talk@eros-os.org
>> Message-ID: <85256796.0070F4D3.00@D51MTA03.pok.ibm.com>
>> Date: Sun, 20 Jun 1999 16:29:20 -0400
>> Subject: Re: Fw: Some very thought-provoking ideas about OS architecture.
>>
>> ** MOTIVATION FOR TRANSPARENT PERSISTENCE
>>
>> [...]
>>
>> 1. Process-managed (explicit) transactions. Each process tracks its own state,
>> saves what it needs to, and engages in traditional transactions with other
>> processes when it needs to in order to remain consistent. There are two
>> problems with this approach:
>>
>> a.) Overhead is prohibitive. Things rapidly converge on requiring every
>> operation to be transacted, at which point you are paying a lot of overhead to
>> do the same thing everywhere, and you should begin to consider centralizing the
>> function. The Vino folks are very proud of their in-kernel transaction
>> overheads and rollback mechanisms, and their implementation is actually quite
>> good. They add a factor of over 100X to every kernel operation. On this basis,
>> I argue that this approach is prohibitive.
>>
>> b) It doesn't work. Once you introduce transactions, things are subject to
>> rollback. This introduces a security problem. If I share a service with a
>> sensitive application (e.g. we indirectly share the X server), then by rolling
>> back a transaction perniciously I can cause the sensitive service to alter its
>> behavior and violate its contracts with third parties.
>>
>> 2. System-managed transactions at process granularity. In this design, the
>> system keeps track of which processes have communicated. Whenever a process
>> commits, everything causally prior to it is committed. This can be done, and it
>> is worth investigating. Our observation is that all applications share in
>> common the system storage allocator and the login agent(s). Many share the
>> display driver. Given this, our expectation is that the set of things that have
>> to commit converges rapidly on the entire system unless transactions are
>> explicitly managed. This appears to be supported by observations of behavior in
>> EROS and KeyKOS.
>>
>> 3. System-wide (i.e. global) checkpoint. In this design, the entire machine is
>> periodically snapshotted and written to disk. This is the EROS and KeyKOS
>> design. It can be done with very low overhead.
>>
>>
>> Jonathan S. Shapiro, Ph. D.
>> IBM T.J. Watson Research Center
>> Email: shapj@us.ibm.com
>> Phone: +1 914 784 7085 (Tieline: 863)
>> Fax: +1 914 784 7595
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/