Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Oct 2005 13:40:04 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        "Poul-Henning Kamp" <phk@phk.freebsd.dk>
Cc:        src-committers@FreeBSD.org, Andre Oppermann <andre@FreeBSD.org>, Bruce Evans <bde@zeta.org.au>, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Andre Oppermann <oppermann@networx.ch>
Subject:   Re: Timekeeping [Was: Re: cvs commit: src/usr.bin/vmstat vmstat.c src/usr.bin/w w.c] 
Message-ID:  <440C26C7-38DF-45C8-A36C-31BB75454FE7@xcllnt.net>
In-Reply-To: <31753.1129924404@critter.freebsd.dk>
References:  <31753.1129924404@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help

On Oct 21, 2005, at 12:53 PM, Poul-Henning Kamp wrote:

> In message <01DFB595-5279-4D3A-BEDA-5F0285E9519B@xcllnt.net>,  
> Marcel Moolenaar
> writes:
>
>
>>> I think we need the definition to consider if (process- ?)state is
>>> retained while the system is unconcious or not.
>>>
>>
>> I'm not sure. I think that might be what makes the definition
>> complex.
>>
>
> Actually I don't think it does, it simplifies it.
>
> If a process survives across the "unconcious" period, then it follows
> that CLOCK_MONOTONIC cannot be reset to zero in relation to the
> unconcious period.

Yes, true. But technically speaking, this has no inherent relation
to uptime other than in our implementation. It should be perfectly
valid to preserve the value of CLOCK_MONOTONIC and not reset it
across (some) non-operational states while resetting uptime for those
states. Processes just need to be informed about a reset in uptime
when they are sensitive to it (and let the system know about it).

>     select(...., {3m0s})
>     suspend
>     [ 2 minutes pass ]
>     resume
>
> When does select time out ?
>
>     One minute after the resume ?
>
>     Three minutes after the resume ?
>
>     Right after the resume with a special errno ?

Ah, yes. These are the interesting questions. One possible attempt
to solve the problem is that if time is not tracked during the
suspend, the suspension has not or can be treated as not having
happened. The answer then would be 3 minutes. If time is tracked
during the suspension, the select should timeout 1 minute after
resume.

Another possible solution would be: it depends on what CLOCK_MONOTONIC
does. It's probably good to have CLOCK_MONOTONIC represent a difference
of 3 minutes when sampled across the timed-out select(2).

Anyway: I have not invested anything in understanding timekeeping
so I basically don't have any grounds for the statements I make.
I think I'd better leave the details to others. I just found the
question of what the definition of uptime is interesting in a
metaphysical way...

-- 
  Marcel Moolenaar         USPA: A-39004          marcel@xcllnt.net





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?440C26C7-38DF-45C8-A36C-31BB75454FE7>