On 01/04/17 09:37, Paul Goyette wrote:
On Wed, 4 Jan 2017, Frank Kardel wrote:
I would also suggest a 64 bit fraction like in struct bintime, which
we already have and use internally for timekeeping anyway along with
the timespec, timeval conversion functions.
Thus collecting can be faster as
On Wed, 4 Jan 2017, Christos Zoulas wrote:
On Jan 5, 9:28am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/sys
| On Thu, 5 Jan 2017, Paul Goyette wrote:
|
| > It seems that pretty much everyone is in favor of using bintime() for the
| > "raw" timestamp data in kernhis
On Jan 5, 9:28am, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/sys
| On Thu, 5 Jan 2017, Paul Goyette wrote:
|
| > It seems that pretty much everyone is in favor of using bintime() for the
| > "raw" timestamp data in kernhist. I'll go ahead and start working on the
On Thu, 5 Jan 2017, Paul Goyette wrote:
It seems that pretty much everyone is in favor of using bintime() for the
"raw" timestamp data in kernhist. I'll go ahead and start working on the
required changes.
One last question: Does this require a kernel version bump?
I didn't bump previously,
On Wed, 4 Jan 2017, Frank Kardel wrote:
Completely agreed, That's why I proposed to consider struct bintime.
We can tackle various aspects of improving the implementations benefiting
from the improved APIs at any time later.
IMHO struct bintime is sufficiently powerful enough to cover the inte
Completely agreed, That's why I proposed to consider struct bintime.
We can tackle various aspects of improving the implementations
benefiting from the improved APIs at any time later.
IMHO struct bintime is sufficiently powerful enough to cover the
interface stability requirements (nsec are al
Date:Wed, 04 Jan 2017 22:06:35 +0100
From:Frank Kardel
Message-ID: <586d63db.9060...@netbsd.org>
| The extendend resolution would be done providing the API.
IMO, what is important right now, is that when designing new APIs
(which is what Paul is doing) (and or chan
> Modified Files:
> src/sys/ddb: db_interface.h
>
> Log Message:
> add a simple stacktrace macro
thanks! this is always annoying to do.
.mrg.
Date: Wed, 04 Jan 2017 10:58:47 +0100
From: Frank Kardel
I agree, the decision is whether we want bintime in the export format.
Sounds good to me. We should use bintime more often. I have been
meaning to add some high-resolution timer-related APIs that use it,
e.g. cv_timedwaitbt, but
There are two things - the extended resolution and general timing handling.
The extendend resolution would be done providing the API. But there is
quite some work
to make the APIs fullfull the expectations. For that we would need to go
into
the tickless direction and use precicion (one-) time
Date: Wed, 04 Jan 2017 14:51:01 +0700
From: Robert Elz
Date:Wed, 04 Jan 2017 14:23:12 +0700
From:Robert Elz
Message-ID: <3987.1483514...@andromeda.noi.kre.to>
Ignore this gibberish..
| division into a constant is equvalent to multiplication b
> The get-versions are cheaper, but they only provide a cached timestamp
> from basically the last hardclock() event. So they are not really
> suitable for
> high resolution time stamping - but probably ok for file system time
> stamps and probably device drivers.
for fwiw, i think we may want
I agree, the decision is whether we want bintime in the export format.
For the microtime/nanotime question (see kern/kern_tc.c):
binuptime()=scaled time counter read
bintime()=binuptime()+bootimeoffset
nanotime()=bintime()+bintime2timespec()
microtime()=bintime()+bintime2timeval()
On Wed, 4 Jan 2017, Frank Kardel wrote:
On 01/04/17 09:37, Paul Goyette wrote:
On Wed, 4 Jan 2017, Frank Kardel wrote:
I would also suggest a 64 bit fraction like in struct bintime, which we
already have and use internally for timekeeping anyway along with the
timespec, timeval conversion fu
On Wed, 4 Jan 2017, Frank Kardel wrote:
I would also suggest a 64 bit fraction like in struct bintime, which we
already have and use internally for timekeeping anyway along with the
timespec, timeval conversion functions.
Thus collecting can be faster as we don't need to make the conversions wh
I would also suggest a 64 bit fraction like in struct bintime, which we
already have and use internally for timekeeping anyway along with the
timespec, timeval conversion functions.
Thus collecting can be faster as we don't need to make the conversions
when collectiing. I deem converting at user
16 matches
Mail list logo