--1ccMZA6j1vT5UqiK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 01, 2006 at 11:18:30AM +0100, Liam J. Foy wrote:
> On 23:24, Fri 31 Mar 06, Bill Studenmund wrote:
> > On Fri, Mar 31, 2006 at 10:54:34PM +0200, Havard Eidnes wrote:
> > My concern with "checkpointing", as it's described so far, is that it
> > really only permits you one level of checkpointing, for a lot of work. =
=20
> > We: 1) double the number of counters, 2) incriment these extra counters
> > (ok, this isn't so bad, and could be adjusted with some implementation
> > magic so that you only incriment one counter), 3) teach almost all
> > counter-using programs about these new counters, and 4) teach
> > administrators about all these new counters. And we only get one
> > checkpoint.
>=20
> Well, you wouldn't really be incrementing these other counters at all,
> merely copying them so no magic implementation would really be needed
> from how I see it.

Huh? What you said touches on point (2) above, but not on any of the other=
=20
points. Sure, we can make it so we only incriment one counter, but that's=
=20
the easy part of all this.

The "magic" is that userland thinks there are multiple counters when there=
=20
aren't (I think it'd be a bad idea to make userland fetch a counter and an=
=20
offset and have to do the subtraction).

But points (1) and (2) are the easy ones. They aren't why I think separate
counters are too much work for the benefit. That's in points (3), (4), and
the lack of scalability. :-)

Take care,

Bill

--1ccMZA6j1vT5UqiK
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEMVDlWz+3JHUci9cRAvG3AJ0eDO5jpFo+FgjP9KpiySdrwIYKJwCfc7oA
TLzFRfE2oHjWlhb/45FJCSY=
=Wn1n
-----END PGP SIGNATURE-----

--1ccMZA6j1vT5UqiK--