Messages in this thread | | | Date | Tue, 22 Jun 1999 14:51:26 -0400 (EDT) | From | Chris Small <> |
| |
alan@lxorguk.ukuu.org.uk Subject: transaction overhead Cc: dholland@hcs.harvard.edu
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/
| |