Subject: transaction overhead
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?
>> From: email@example.com
>> To: firstname.lastname@example.org
>> cc: email@example.com, firstname.lastname@example.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: email@example.com
>> Phone: +1 914 784 7085 (Tieline: 863)
>> Fax: +1 914 784 7595