The patch has been splitted in smaller logical chunks in order to
improve readability and facilitate review.
The whole code can be found here:
http://people.freebsd.org/~davide/calloutng_split/
In particular:
http://people.freebsd.org/~davide/calloutng_split/sbintime.diff brings
the new type
On Thu, Feb 14, 2013 at 11:56:54PM -0800, Alfred Perlstein wrote:
[ added Luigi Rizzo to thread ]
On 2/11/13 12:26 PM, Davide Italiano wrote:
[trimmed old mails]
Here's a new version of the patch:
http://people.freebsd.org/~davide/patches/calloutng-11022012.diff
Significant bits
[ added Luigi Rizzo to thread ]
On 2/11/13 12:26 PM, Davide Italiano wrote:
[trimmed old mails]
Here's a new version of the patch:
http://people.freebsd.org/~davide/patches/calloutng-11022012.diff
Significant bits changed (after wider discussion and suggestion by phk@):
- Introduction of the
[trimmed old mails]
Here's a new version of the patch:
http://people.freebsd.org/~davide/patches/calloutng-11022012.diff
Significant bits changed (after wider discussion and suggestion by phk@):
- Introduction of the new sbintime_t type (32.32 fixed point) with the
respective conversion
On Sun, Jan 13, 2013 at 09:36:11PM +0200, Alexander Motin wrote:
On 13.01.2013 20:09, Marius Strobl wrote:
On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote:
On 06.01.2013 17:23, Marius Strobl wrote:
I'm not really sure what to do about that. Earlier you already said
that
On Thu, 17 Jan 2013, Ian Lepore wrote:
On Mon, 2013-01-14 at 11:38 +1100, Bruce Evans wrote:
Er, timecounters are called with a spin mutex held in existing code:
though it is dangerous to do so, timecounters are called from fast
interrupt handlers for very timekeeping-critical purposes:
- to
On Mon, 2013-01-14 at 11:38 +1100, Bruce Evans wrote:
On Sun, 13 Jan 2013, Alexander Motin wrote:
On 13.01.2013 20:09, Marius Strobl wrote:
On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote:
[...]
In existing code in HEAD and 9 timecounters are never called with spin
On Sun, 2012-12-30 at 16:13 -0700, Ian Lepore wrote:
On Wed, 2012-12-26 at 21:24 +0200, Alexander Motin wrote:
[...]
I grabbed testsleep.c to test an arm event timer implementation, and had
to fix a couple nits... kqueueto was missing from the names[] array, and
I had to add a * 1000 to
On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote:
On 06.01.2013 17:23, Marius Strobl wrote:
On Wed, Dec 26, 2012 at 09:24:46PM +0200, Alexander Motin wrote:
On 26.12.2012 01:21, Marius Strobl wrote:
On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote:
Ok,
So everyone - what _could_ be brought into -HEAD right now, without
any actual change in code behaviour?
eg, what kind of refactoring could be done to reduce the amount of
diffs between the branch and -HEAD?
Adrian
___
On 13.01.2013 20:09, Marius Strobl wrote:
On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote:
On 06.01.2013 17:23, Marius Strobl wrote:
I'm not really sure what to do about that. Earlier you already said
that sched_bind(9) also isn't an option in case if td_critnest 1.
To be
On Sun, 2013-01-13 at 21:36 +0200, Alexander Motin wrote:
On 13.01.2013 20:09, Marius Strobl wrote:
[...]
Uhm, there are no NMIs on sparc64. Does it make sense to bypass this
adjustment on sparc64?
If it is not possible or not good to to stop timer during programming,
there will always
On 14.01.2013 01:10, Ian Lepore wrote:
On Sun, 2013-01-13 at 21:36 +0200, Alexander Motin wrote:
On 13.01.2013 20:09, Marius Strobl wrote:
[...]
Uhm, there are no NMIs on sparc64. Does it make sense to bypass this
adjustment on sparc64?
If it is not possible or not good to to stop timer
On Sun, 13 Jan 2013, Alexander Motin wrote:
On 13.01.2013 20:09, Marius Strobl wrote:
On Tue, Jan 08, 2013 at 12:46:57PM +0200, Alexander Motin wrote:
On 06.01.2013 17:23, Marius Strobl wrote:
I'm not really sure what to do about that. Earlier you already said
that sched_bind(9) also isn't
On 06.01.2013 17:23, Marius Strobl wrote:
On Wed, Dec 26, 2012 at 09:24:46PM +0200, Alexander Motin wrote:
On 26.12.2012 01:21, Marius Strobl wrote:
On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote:
Experiments with dummynet shown ineffective support for very short
tick-based
On 06.01.2013 18:20, Luigi Rizzo wrote:
On Sun, Jan 06, 2013 at 04:23:13PM +0100, Marius Strobl wrote:
On Wed, Dec 26, 2012 at 09:24:46PM +0200, Alexander Motin wrote:
Here is small tool we are using for test correctness and performance of
different user-level APIs:
On Tue, Jan 08, 2013 at 12:55:27PM +0200, Alexander Motin wrote:
On 06.01.2013 18:20, Luigi Rizzo wrote:
...
I think that for the time being it would be useful to run at least
one set of tests with kern.timecounter.alloweddeviation=0 so we can
tell how close we get to the required timeouts
On Wed, Dec 26, 2012 at 09:24:46PM +0200, Alexander Motin wrote:
On 26.12.2012 01:21, Marius Strobl wrote:
On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote:
Experiments with dummynet shown ineffective support for very short
tick-based callouts. New version fixes that,
On Sun, Jan 06, 2013 at 04:23:13PM +0100, Marius Strobl wrote:
On Wed, Dec 26, 2012 at 09:24:46PM +0200, Alexander Motin wrote:
On 26.12.2012 01:21, Marius Strobl wrote:
On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote:
Experiments with dummynet shown ineffective support
On Wed, Jan 02, 2013 at 09:52:37PM -0800, Kevin Oberman wrote:
On Wed, Jan 2, 2013 at 2:06 PM, Alexander Motin m...@freebsd.org wrote:
On 02.01.2013 18:08, Adrian Chadd wrote:
.. I'm pretty damned sure we're going to need to enforce a never
earlier than X latency.
Do you mean here
On Wed, 2 Jan 2013, Alexander Motin wrote:
On 02.01.2013 19:09, Konstantin Belousov wrote:
On Wed, Jan 02, 2013 at 05:22:06PM +0100, Luigi Rizzo wrote:
Probably one way to close this discussion would be to provide
a sysctl so the sysadmin can decide which point in the interval
to pick when
On 03.01.2013 16:45, Bruce Evans wrote:
On Wed, 2 Jan 2013, Alexander Motin wrote:
More important for scheduling fairness thread's CPU percentage is also
based on hardclock() and hiding from it was trivial before, since all
sleep primitives were strictly aligned to hardclock(). Now it is
On Thu, 3 Jan 2013, Alexander Motin wrote:
On 03.01.2013 16:45, Bruce Evans wrote:
On Wed, 2 Jan 2013, Alexander Motin wrote:
More important for scheduling fairness thread's CPU percentage is also
based on hardclock() and hiding from it was trivial before, since all
sleep primitives were
On Mon, Dec 31, 2012 at 12:17:27PM +0200, Alexander Motin wrote:
On 31.12.2012 08:17, Luigi Rizzo wrote:
On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote:
...
Then I noticed you had a 12_26 patchset so I tested
that (after crudely fixing a couple uninitialized var warnings), and it
On 02.01.2013 12:57, Luigi Rizzo wrote:
On Mon, Dec 31, 2012 at 12:17:27PM +0200, Alexander Motin wrote:
On 31.12.2012 08:17, Luigi Rizzo wrote:
On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote:
...
Then I noticed you had a 12_26 patchset so I tested
that (after crudely fixing a
On Wed, Jan 02, 2013 at 01:24:26PM +0200, Alexander Motin wrote:
On 02.01.2013 12:57, Luigi Rizzo wrote:
...
i am not sure what you mean by extending interval, but i believe the
logic should be the following:
- say user requests a timeout after X seconds and with a tolerance of D
second
02.01.2013 14:28 пользователь Luigi Rizzo ri...@iet.unipi.it написал:
On Wed, Jan 02, 2013 at 01:24:26PM +0200, Alexander Motin wrote:
On 02.01.2013 12:57, Luigi Rizzo wrote:
...
i am not sure what you mean by extending interval, but i believe the
logic should be the following:
- say
On Wed, 2013-01-02 at 15:11 +0200, Alexander Motin wrote:
02.01.2013 14:28 пользователь Luigi Rizzo ri...@iet.unipi.it написал:
On Wed, Jan 02, 2013 at 01:24:26PM +0200, Alexander Motin wrote:
On 02.01.2013 12:57, Luigi Rizzo wrote:
First of all, if you know that there is already a
On Wed, Jan 02, 2013 at 03:11:05PM +0200, Alexander Motin wrote:
...
First of all, if you know that there is already a hardclock/statclock/*
scheduled in [T_X, T_X+D] you just reuse that. This particular bullet
was no event scheduled in [T_X, T_X+D] so you need to generate
a new one.
On Wed, Jan 02, 2013 at 05:22:06PM +0100, Luigi Rizzo wrote:
On Wed, Jan 02, 2013 at 03:11:05PM +0200, Alexander Motin wrote:
...
First of all, if you know that there is already a hardclock/statclock/*
scheduled in [T_X, T_X+D] you just reuse that. This particular bullet
was no event
.. I'm pretty damned sure we're going to need to enforce a never
earlier than X latency.
Is there a more detailed writeup of calloutng somewhere, besides
David's slides? The wiki page is rather empty.
Eg - I think this work does coalesce wakeups, right? Or it can? So
when in low-power scenarios
On 02.01.2013 19:09, Konstantin Belousov wrote:
On Wed, Jan 02, 2013 at 05:22:06PM +0100, Luigi Rizzo wrote:
Probably one way to close this discussion would be to provide
a sysctl so the sysadmin can decide which point in the interval
to pick when there is no suitable callout already scheduled.
On 02.01.2013 18:08, Adrian Chadd wrote:
.. I'm pretty damned sure we're going to need to enforce a never
earlier than X latency.
Do you mean here that we should never wake up before specified time
(just as specified by the most of existing APIs), or that we should not
allow sleep shorter
On Wed, Jan 2, 2013 at 2:06 PM, Alexander Motin m...@freebsd.org wrote:
On 02.01.2013 18:08, Adrian Chadd wrote:
.. I'm pretty damned sure we're going to need to enforce a never
earlier than X latency.
Do you mean here that we should never wake up before specified time (just as
specified
On Sun, Dec 30, 2012 at 10:17 PM, Luigi Rizzo ri...@iet.unipi.it wrote:
On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote:
...
I grabbed testsleep.c to test an arm event timer implementation, and had
to fix a couple nits... kqueueto was missing from the names[] array, and
I had to
On 31.12.2012 08:17, Luigi Rizzo wrote:
On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote:
...
I grabbed testsleep.c to test an arm event timer implementation, and had
to fix a couple nits... kqueueto was missing from the names[] array, and
I had to add a * 1000 to a couple places
On Mon, 2012-12-31 at 12:17 +0200, Alexander Motin wrote:
On 31.12.2012 08:17, Luigi Rizzo wrote:
On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote:
...
I grabbed testsleep.c to test an arm event timer implementation, and had
to fix a couple nits... kqueueto was missing from the
On 31.12.2012 17:02, Ian Lepore wrote:
On Mon, 2012-12-31 at 12:17 +0200, Alexander Motin wrote:
On 31.12.2012 08:17, Luigi Rizzo wrote:
On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote:
...
I grabbed testsleep.c to test an arm event timer implementation, and had
to fix a couple
On Wed, 2012-12-26 at 21:24 +0200, Alexander Motin wrote:
On 26.12.2012 01:21, Marius Strobl wrote:
On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote:
Experiments with dummynet shown ineffective support for very short
tick-based callouts. New version fixes that, allowing to
On Sun, Dec 30, 2012 at 04:13:43PM -0700, Ian Lepore wrote:
...
I grabbed testsleep.c to test an arm event timer implementation, and had
to fix a couple nits... kqueueto was missing from the names[] array, and
I had to add a * 1000 to a couple places where usec was stuffed into a
timespec's
On 26.12.2012 01:21, Marius Strobl wrote:
On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote:
Experiments with dummynet shown ineffective support for very short
tick-based callouts. New version fixes that, allowing to get as many
tick-based callout events as hz value permits, while
On Tue, Dec 18, 2012 at 11:03:47AM +0200, Alexander Motin wrote:
Experiments with dummynet shown ineffective support for very short
tick-based callouts. New version fixes that, allowing to get as many
tick-based callout events as hz value permits, while still be able to
aggregate events and
On Wed, Dec 19, 2012 at 11:00:06AM +, Poul-Henning Kamp wrote:
In message 50d192e8.3020...@freebsd.org, Alexander Motin writes:
Linux uses 32.32 format in their eventtimers code.
(And that is no accident, I know who they got the number from :-)
But if at some point we want to
In message 2012125025.ga46...@stack.nl, Jilles Tjoelker writes:
Either way, such a facility should be layered on top of the callout
facility, which should always run in elapsed time[1] with no attention
paid to what NTPD might do to the UTC estimate.
POSIX specifies functions
Fabian Keil freebsd-lis...@fabiankeil.de wrote:
Alexander Motin m...@freebsd.org wrote:
On 20.12.2012 15:26, Fabian Keil wrote:
Alexander Motin m...@freebsd.org wrote:
On 20.12.2012 12:56, Fabian Keil wrote:
Alexander Motin m...@freebsd.org wrote:
Experiments with dummynet
On 21.12.2012 14:16, Fabian Keil wrote:
Fabian Keil freebsd-lis...@fabiankeil.de wrote:
Alexander Motin m...@freebsd.org wrote:
On 20.12.2012 15:26, Fabian Keil wrote:
Alexander Motin m...@freebsd.org wrote:
On 20.12.2012 12:56, Fabian Keil wrote:
Alexander Motin m...@freebsd.org wrote:
Alexander Motin m...@freebsd.org wrote:
Experiments with dummynet shown ineffective support for very short
tick-based callouts. New version fixes that, allowing to get as many
tick-based callout events as hz value permits, while still be able to
aggregate events and generating minimum of
On 20.12.2012 12:56, Fabian Keil wrote:
Alexander Motin m...@freebsd.org wrote:
Experiments with dummynet shown ineffective support for very short
tick-based callouts. New version fixes that, allowing to get as many
tick-based callout events as hz value permits, while still be able to
Alexander Motin m...@freebsd.org wrote:
On 20.12.2012 12:56, Fabian Keil wrote:
Alexander Motin m...@freebsd.org wrote:
Experiments with dummynet shown ineffective support for very short
tick-based callouts. New version fixes that, allowing to get as many
tick-based callout events as
On 20.12.2012 15:26, Fabian Keil wrote:
Alexander Motin m...@freebsd.org wrote:
On 20.12.2012 12:56, Fabian Keil wrote:
Alexander Motin m...@freebsd.org wrote:
Experiments with dummynet shown ineffective support for very short
tick-based callouts. New version fixes that, allowing to get as
Alexander Motin m...@freebsd.org wrote:
On 20.12.2012 15:26, Fabian Keil wrote:
Alexander Motin m...@freebsd.org wrote:
On 20.12.2012 12:56, Fabian Keil wrote:
Alexander Motin m...@freebsd.org wrote:
Experiments with dummynet shown ineffective support for very short
tick-based
On 19.12.2012 01:37, Ian Lepore wrote:
On Wed, 2012-12-19 at 00:29 +0100, Luigi Rizzo wrote:
On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote:
On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote:
[top posting for readability;
in summary we were discussing the new callout API trying
In message 1355873265.1198.183.ca...@revolution.hippie.lan, Ian Lepore writes
:
On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote:
I'm not so sure about the 2^k precision. You speak of seconds, but I
would be worrying about sub-second precision in my work.
It is a bad idea, and it
On Wed, Dec 19, 2012 at 1:54 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message 1355873265.1198.183.ca...@revolution.hippie.lan, Ian Lepore
writes
:
On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote:
I'm not so sure about the 2^k precision. You speak of seconds, but I
On 19.12.2012 12:03, Davide Italiano wrote:
On Wed, Dec 19, 2012 at 1:54 AM, Poul-Henning Kamp p...@phk.freebsd.dk wrote:
In message 1355873265.1198.183.ca...@revolution.hippie.lan, Ian Lepore writes
:
On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote:
I'm not so sure about the
In message CACYV=-eg542ihm9kfujpvczzra4tqepebva8rzt1yohncgf...@mail.gmail.com
, Davide Italiano writes:
Right now -- the precision is specified in 'bintime', which is a binary number.
It's not 32.32, it's 32.64 or 64.64 depending on the size of time_t in
the specific platform.
And that
In message 50d192e8.3020...@freebsd.org, Alexander Motin writes:
Linux uses 32.32 format in their eventtimers code.
(And that is no accident, I know who they got the number from :-)
But if at some point we want to be able to
handle absolute wall time, [...]
Then you have other
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
In message CACYV=-eg542ihm9kfujpvczzra4tqepebva8rzt1yohncgf...@mail.gmail.com
, Davide Italiano writes:
Right now -- the precision is specified in 'bintime', which is a binary number.
It's not 32.32, it's 32.64 or 64.64 depending on the
In message 20121219221518.e1...@besplex.bde.org, Bruce Evans writes:
With this format you can specify callouts 68 years into the future
with quarter nanosecond resolution, and you can trivially and
efficiently compare dur_t's with
if (d1 d2)
This would make a better general
On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans b...@optusnet.com.au wrote:
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
In message
CACYV=-eg542ihm9kfujpvczzra4tqepebva8rzt1yohncgf...@mail.gmail.com
, Davide Italiano writes:
Right now -- the precision is specified in 'bintime',
In message 20121220005706.i1...@besplex.bde.org, Bruce Evans writes:
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
Except that for absolute timescales, we're running out of the 32 bits
integer part.
Except 32 bit time_t works until 2106 if it is unsigned.
That's sort of not an
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
In message 20121219221518.e1...@besplex.bde.org, Bruce Evans writes:
With this format you can specify callouts 68 years into the future
with quarter nanosecond resolution, and you can trivially and
efficiently compare dur_t's with
On Wed, Dec 19, 2012 at 10:51:48AM +, Poul-Henning Kamp wrote:
In message
CACYV=-eg542ihm9kfujpvczzra4tqepebva8rzt1yohncgf...@mail.gmail.com
, Davide Italiano writes:
Right now -- the precision is specified in 'bintime', which is a binary
number.
It's not 32.32, it's 32.64
In message 20121219150809.ga98...@onelab2.iet.unipi.it, Luigi Rizzo writes:
typedef dur_t int64_t;/* signed for bug catching */
#define DURSEC ((dur_t)1 32)
#define DURMIN (DURSEC * 60)
#define DURMSEC (DURSEC / 1000)
#define
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
dropping phk _AT_ onelab2 _DOT_ something from CC as long as it
doesn't seem a valid mail address and I'm annoyed mails bounce back.
On Wed, Dec 19, 2012 at 6:20 AM, Bruce Evans b...@optusnet.com.au wrote:
On Wed, 19 Dec 2012, Davide Italiano wrote:
On Wed, Dec 19, 2012 at 4:18 AM, Bruce Evans
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
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
In message 20121220005706.i1...@besplex.bde.org, Bruce Evans writes:
On Wed, 19 Dec 2012, Poul-Henning Kamp wrote:
Except that for absolute timescales, we're running out of the 32 bits
integer part.
Except 32 bit time_t works until
In message 50d1e0d8.9070...@freebsd.org, Alexander Motin writes:
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
I finally remembered to remove the .it phk :-).
On Wed, 19 Dec 2012, Luigi Rizzo wrote:
On Wed, Dec 19, 2012 at 10:51:48AM +, Poul-Henning Kamp wrote:
...
As I said in my previous email:
typedef dur_t int64_t;/* signed for bug catching */
#define DURSEC
Experiments with dummynet shown ineffective support for very short
tick-based callouts. New version fixes that, allowing to get as many
tick-based callout events as hz value permits, while still be able to
aggregate events and generating minimum of interrupts.
Also this version modifies
On Mon, Dec 17, 2012 at 01:22:59PM -0800, Adrian Chadd wrote:
Personally, I'd rather see some consistently used units here..
bintime (or something similar) is the correct choice here.
If we are concerned about the size (128 bit) then we
can map it to a shorter, fixed point format, such
as
On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote:
Hi.
I would instead do the following:
I also don't very like the wide API and want to hear fresh ideas, but
approaches to time measurement there are too different to do what you
are proposing. Main problem is that while
On Tue, Dec 18, 2012 at 06:36:43PM +0100, Luigi Rizzo wrote:
On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote:
...
So I believe my proposal would give large simplifications in
the code and lead to a much cleaner implementation of what
you have designed:
1. acknowledge the
On 18.12.2012 19:36, Luigi Rizzo wrote:
On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote:
I would instead do the following:
I also don't very like the wide API and want to hear fresh ideas, but
approaches to time measurement there are too different to do what you
are proposing.
On 18.12.2012 20:03, Alexander Motin wrote:
On 18.12.2012 19:36, Luigi Rizzo wrote:
On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote:
I would instead do the following:
I also don't very like the wide API and want to hear fresh ideas, but
approaches to time measurement there
[top posting for readability;
in summary we were discussing the new callout API trying to avoid
an explosion of methods and arguments while at the same time
supporting the old API and the new one]
(I am also Cc-ing phk as he might have better insight
on the topic).
I think the patch you propose
On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote:
[top posting for readability;
in summary we were discussing the new callout API trying to avoid
an explosion of methods and arguments while at the same time
supporting the old API and the new one]
(I am also Cc-ing phk as he might have
On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote:
On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote:
[top posting for readability;
in summary we were discussing the new callout API trying to avoid
an explosion of methods and arguments while at the same time
supporting the old
On Wed, 2012-12-19 at 00:29 +0100, Luigi Rizzo wrote:
On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote:
On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote:
[top posting for readability;
in summary we were discussing the new callout API trying to avoid
an explosion of
On Tue, Dec 18, 2012 at 04:37:10PM -0700, Ian Lepore wrote:
On Wed, 2012-12-19 at 00:29 +0100, Luigi Rizzo wrote:
On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote:
On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote:
[top posting for readability;
in summary we were
On 17.12.2012 03:29, Adrian Chadd wrote:
On 16 December 2012 15:37, Alexander Motin m...@freebsd.org wrote:
Here is one more version. Unless something new will be found/reported this
may be the last one, because me and Davide are quite satisfied with the
results. If everything will be fine, I
On 17.12.2012 05:38, Adrian Chadd wrote:
On 16 December 2012 18:31, Garrett Cooper yaneg...@gmail.com wrote:
Would you mind approaching some of the cluster peeps and seeing if
they'll run this up on the ref10* boxes and VMs, just to get some
further exposure?
And maybe tinderbox..?
On 16 December 2012 23:57, Andriy Gapon a...@freebsd.org wrote:
Thank god that this feature was developed in a branch, it was developed for a
long period of time and there were people who routinely reviewed and tested
(and
really used) it. And yeah, its design was announced and discussed
On Mon, Dec 17, 2012 at 10:14:29AM +0200, Alexander Motin wrote:
On 17.12.2012 05:38, Adrian Chadd wrote:
...
Maybe hit up the altq/pf using crowd and see if they'll test this stuff
out too?
It would be good to test, though I know that at least dummynet is
written awful from the point of
[addressing the various items separately]
On Fri, Dec 14, 2012 at 01:57:36PM +0100, Davide Italiano wrote:
On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
...
- for several functions the only change is the name of an argument
from busy to us. Can you elaborate the
Hi.
I wonder why the choice is to use (actually, call) the value
microseconds rather use a bintime or something scaled and with a
well defined resolution.
It was kind of engineering choice. I've chosen microseconds, following
values used by ACPI to represent CPU sleep states exit latencies.
[again, response to another issue i raised]
On Fri, Dec 14, 2012 at 01:57:36PM +0100, Davide Italiano wrote:
On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
...
Finally, a more substantial comment:
- a lot of functions which formerly had only a timo argument
now
On Mon, Dec 17, 2012 at 11:27 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
[addressing the various items separately]
On Fri, Dec 14, 2012 at 01:57:36PM +0100, Davide Italiano wrote:
On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
...
- for several functions the only
Hi.
I would instead do the following:
I also don't very like the wide API and want to hear fresh ideas, but
approaches to time measurement there are too different to do what you
are proposing. Main problem is that while ticks value is relative,
bintime is absolute. It is not easy to make
On Mon, Dec 17, 2012 at 12:17:54PM -0800, Davide Italiano wrote:
On Mon, Dec 17, 2012 at 11:27 AM, Luigi Rizzo ri...@iet.unipi.it wrote:
[addressing the various items separately]
On Fri, Dec 14, 2012 at 01:57:36PM +0100, Davide Italiano wrote:
On Fri, Dec 14, 2012 at 7:41 AM, Luigi Rizzo
Personally, I'd rather see some consistently used units here..
Adrian
___
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
In message 50cf79ad.9040...@freebsd.org, Alexander Motin writes:
Hi.
I wonder why the choice is to use (actually, call) the value
microseconds rather use a bintime or something scaled and with a
well defined resolution.
It was kind of engineering choice. I've chosen microseconds
On Sat, Dec 15, 2012 at 11:13:26PM +0200, Alexander Motin wrote:
On 15.12.2012 23:03, Alexander Motin wrote:
Sorry, it's my fault. I've tried to save some time on patch generation
and forgot about that change in lib/. We haven't touched user-level in
our work except that file. Here is patch
On Mon, Dec 17, 2012 at 2:39 PM, David O'Brien obr...@freebsd.org wrote:
On Sat, Dec 15, 2012 at 11:13:26PM +0200, Alexander Motin wrote:
On 15.12.2012 23:03, Alexander Motin wrote:
Sorry, it's my fault. I've tried to save some time on patch generation
and forgot about that change in lib/.
On Sat, 15 Dec 2012, Garrett Cooper wrote:
On Dec 15, 2012, at 12:34 PM, Mark Johnston wrote:
On Sat, Dec 15, 2012 at 06:55:53PM +0200, Alexander Motin wrote:
Hi.
I'm sorry to interrupt review, but as usual good ideas came during the
final testing, causing another round. :) Here is updated
Hi.
Here is one more version. Unless something new will be found/reported
this may be the last one, because me and Davide are quite satisfied with
the results. If everything will be fine, I think we could commit it to
HEAD closer to the end of the week:
On 16 December 2012 15:37, Alexander Motin m...@freebsd.org wrote:
Hi.
Here is one more version. Unless something new will be found/reported this
may be the last one, because me and Davide are quite satisfied with the
results. If everything will be fine, I think we could commit it to HEAD
On Dec 16, 2012, at 5:29 PM, Adrian Chadd adr...@freebsd.org wrote:
On 16 December 2012 15:37, Alexander Motin m...@freebsd.org wrote:
Hi.
Here is one more version. Unless something new will be found/reported this
may be the last one, because me and Davide are quite satisfied with the
On 16 December 2012 18:31, Garrett Cooper yaneg...@gmail.com wrote:
Would you mind approaching some of the cluster peeps and seeing if
they'll run this up on the ref10* boxes and VMs, just to get some
further exposure?
And maybe tinderbox..?
Tinderbox is a great idea.
Maybe hit up the
1 - 100 of 120 matches
Mail list logo
