On 19.12.2012 16:20, Bruce Evans wrote:
On Wed, 19 Dec 2012, Davide Italiano wrote:
On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans <b...@optusnet.com.au>
wrote:
I would have tried a 32 bit format with a variable named 'ticks'.
Something like:
- ticks >= 0. Same meaning as now. No changes in ABIs or APIs to use
this. The tick period would be constant but for virtual ticks and
not too small. hz = 1000 now makes the period too small, and not a
power of 2. So make the period 1/128 second. This gives a 1.24.7
binary format. 2**24 seconds is 194 days.
- ticks < 0. The 31 value bits are now a cookie (descriptor) referring
to a bintime or whatever. This case should rarely be used. I don't
like it that a tickless kernel, which is needed mainly for power
saving, has expanded into complications to support short timeouts
which should rarely be used.
Bruce, I don't really agree with this.
The data addressed by cookie should be still stored somewhere, and KBI
will result broken. This, indeed, is not real problem as long as
current calloutng code heavily breaks KBI, but if that was your point,
I don't see how your proposed change could help.
In the old API, it is an error to pass ticks < 0, so only broken old
callers are affected. Of course, if there are any then it would be
hard to detect their garbage cookies.
Anywy, it's too later to change to this, and maybe also to a 32.32
format.
It would be late to change this after committing. I would definitely
like it to be done earlier to not redo all the tests, but I think we
could convert callout and eventtimers code to 32.32 format in several
days. The only two questions are: do we really want it (won't there be
any reasons to regret about it) and how do we want it to look?
For the first question my personal showstopper since eventtimers
creation always was the wish to keep consistency. But benefits of 32.32
format are clear, and if there are more votes for it, let's consider. If
now it will be decided that full range will never be useful for callout
subsystem, then it is obviously not needed for eventtimers also.
About the second question, what do you think about such prototypes:
typedef int64_t sbintime_t
static __inline sbintime_t
bintime_shrink(struct bintime *bt)
{}
static __inline struct bintime
bintime_expand(sbintime_t sbt)
{}
...
int
callout_reset_bt(struct callout *, sbintime_t sbt, sbintime_t pr,
void (*fn)(void *), void *arg, int flags);
, where pr used only for absolute precision, and flags includes: direct
execution, absolute/relative time in argument, relative precision in
case of relative sbt, flag for aligning to hardclock() to emulate legacy
behavior, and potentially flags for reaction on suspend/resume.
Another option is to move absolute precision also to flags, using log2()
representation, as we tried and as was proposed before. With possibility
to use precise relative time there will be few cases requiring absolute
value of precision, that should depend on period. Then there will be no
extra arguments in the most usual cases.
Wrapper for existing API compatibility will look just like this:
#define callout_reset(c, ticks, fn, arg) \
callout_reset_bt(c, ticks2sbintime(ticks), -1, \
(fn), (arg), C_HARDCLOCK)
--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
