From: Eric W. Biederman <hidden> Date: 2018-09-28 17:04:11
Thomas Gleixner [off-list ref] writes:
On Wed, 26 Sep 2018, Eric W. Biederman wrote:
quoted
Reading the code the calling sequence there is:
tick_sched_do_timer
tick_do_update_jiffies64
update_wall_time
timekeeping_advance
timekeepging_update
If I read that properly under the right nohz circumstances that update
can be delayed indefinitely.
So I think we could prototype a time namespace that was per
timekeeping_update and just had update_wall_time iterate through
all of the time namespaces.
Please don't go there. timekeeping_update() is already heavy and walking
through a gazillion of namespaces will just make it horrible,
quoted
I don't think the naive version would scale to very many time
namespaces.
:)
quoted
At the same time using the techniques from the nohz work and a little
smarts I expect we could get the code to scale.
You'd need to invoke the update when the namespace is switched in and
hasn't been updated since the last tick happened. That might be doable, but
you also need to take the wraparound constraints of the underlying
clocksources into account, which again can cause walking all name spaces
when they are all idle long enough.
The wrap around constraints being how long before the time sources wrap
around so you have to read them once per wrap around? I have not dug
deeply enough into the code to see that yet.
From there it becomes hairy, because it's not only timekeeping,
i.e. reading time, this is also affecting all timers which are armed from a
namespace.
That gets really ugly because when you do settimeofday() or adjtimex() for
a particular namespace, then you have to search for all armed timers of
that namespace and adjust them.
The original posix timer code had the same issue because it mapped the
clock realtime timers to the timer wheel so any setting of the clock caused
a full walk of all armed timers, disarming, adjusting and requeing
them. That's horrible not only performance wise, it's also a locking
nightmare of all sorts.
Add time skew via NTP/PTP into the picture and you might have to adjust
timers as well, because you need to guarantee that they are not expiring
early.
I haven't looked through Dimitry's patches yet, but I don't see how this
can work at all without introducing subtle issues all over the place.
Then it sounds like this will take some more digging.
Please pardon me for thinking out load.
There are one or more time sources that we use to compute the time
and for each time source we have a conversion from ticks of the
time source to nanoseconds.
Each time source needs to be sampled at least once per wrap-around
and something incremented so that we don't loose time when looking
at that time source.
There are several clocks presented to userspace and they all share the
same length of second and are all fundamentally offsets from
CLOCK_MONOTONIC.
I see two fundamental driving cases for a time namespace.
1) Migration from one node to another node in a cluster in almost
real time.
The problem is that CLOCK_MONOTONIC between nodes in the cluster
has not relation ship to each other (except a synchronized length of
the second). So applications that migrate can see CLOCK_MONOTONIC
and CLOCK_BOOTTIME go backwards.
This is the truly pressing problem and adding some kind of offset
sounds like it would be the solution. Possibly by allowing a boot
time synchronization of CLOCK_BOOTTIME and CLOCK_MONOTONIC.
2) Dealing with two separate time management domains. Say a machine
that needes to deal with both something inside of google where they
slew time to avoid leap time seconds and something in the outside
world proper UTC time is kept as an offset from TAI with the
occasional leap seconds.
In the later case it would fundamentally require having seconds of
different length.
A pure 64bit nanoseond counter is good for 500 years. So 64bit
variables can be used to hold time, and everything can be converted from
there.
This suggests we can for ticks have two values.
- The number of ticks from the time source.
- The number of times the ticks would have rolled over.
That sounds like it may be a little simplistic as it would require being
very diligent about firing a timer exactly at rollover and not losing
that, but for a handwaving argument is probably enough to generate
a 64bit tick counter.
If the focus is on a 64bit tick counter then what update_wall_time
has to do is very limited. Just deal the accounting needed to cope with
tick rollover.
Getting the actual time looks like it would be as simple as now, with
perhaps an extra addition to account for the number of times the tick
counter has rolled over. With limited precision arithmetic and various
optimizations I don't think it is that simple to implement but it feels
like it should be very little extra work.
For timers my inclination would be to assume no adjustments to the
current time parameters and set the timer to go off then. If the time
on the appropriate clock has been changed since the timer was set and
the timer is going off early reschedule so the timer fires at the
appropriate time.
With the above I think it is theoretically possible to build a time
namespace that supports multiple lengths of second, and does not have
much overhead.
Not that I think a final implementation would necessary look like what I
have described. I just think it is possible with extreme care to evolve
the current code base into something that can efficiently handle
multiple time domains with slightly different lenghts of second.
Thomas does it sound like I am completely out of touch with reality?
It does though sound like it is going to take some serious digging
through the code to understand how what everything does and how and why
everthing works the way it does. Not something grafted on top with just
a cursory understanding of how the code works.
Eric
From: Thomas Gleixner <hidden> Date: 2018-09-28 19:32:53
Eric,
On Fri, 28 Sep 2018, Eric W. Biederman wrote:
Thomas Gleixner [off-list ref] writes:
quoted
On Wed, 26 Sep 2018, Eric W. Biederman wrote:
quoted
At the same time using the techniques from the nohz work and a little
smarts I expect we could get the code to scale.
You'd need to invoke the update when the namespace is switched in and
hasn't been updated since the last tick happened. That might be doable, but
you also need to take the wraparound constraints of the underlying
clocksources into account, which again can cause walking all name spaces
when they are all idle long enough.
The wrap around constraints being how long before the time sources wrap
around so you have to read them once per wrap around? I have not dug
deeply enough into the code to see that yet.
It's done by limiting the NOHZ idle time when all CPUs are going into deep
sleep for a long time, i.e. we make sure that at least one CPU comes back
sufficiently _before_ the wraparound happens and invokes the update
function.
It's not so much a problem for TSC, but not every clocksource the kernel
supports has wraparound times in the range of hundreds of years.
But yes, your idea of keeping track of wraparounds might work. Tricky, but
looks feasible on first sight, but we should be aware of the dragons.
Please pardon me for thinking out load.
There are one or more time sources that we use to compute the time
and for each time source we have a conversion from ticks of the
time source to nanoseconds.
Each time source needs to be sampled at least once per wrap-around
and something incremented so that we don't loose time when looking
at that time source.
There are several clocks presented to userspace and they all share the
same length of second and are all fundamentally offsets from
CLOCK_MONOTONIC.
Yes. That's the readout side. This one is doable. But now look at timers.
If you arm the timer from a name space, then it needs to be converted to
host time in order to sort it into the hrtimer queue and at some point arm
the clockevent device for it. This works as long as host and name space
time have a constant offset and the same skew.
Once the name space time has a different skew this falls apart because the
armed timer will either expire late or early.
Late might be acceptable, early violates the spec. You could do an extra
check for rescheduling it, if it's early, but that requires to store the
name space time accessor in the hrtimer itself because not every timer
expiry happens so that it can be checked in the name space context (think
signal based timers). We need to add this extra magic right into
__hrtimer_run_queues() which is called from the hard and soft interrupt. We
really don't want to touch all relevant callbacks or syscalls. The latter
is not sufficient anyway for signal based timer delivery.
That's going to be interesting in terms of synchronization and might also
cause substantial overhead at least for the timers which belong to name
spaces.
But that also means that anything which is early can and probably will
cause rearming of the timer hardware possibly for a very short delta. We
need to think about whether this can be abused to create interrupt storms.
Now if you accept a bit late, which I'm not really happy about, then you
surely won't accept very late, i.e. hours, days. But that can happen when
settimeofday() comes into play. Right now with a single time domain, this
is easy. When settimeofday() or adjtimex() makes time jump, we just go and
reprogramm the hardware timers accordingly, which might also result in
immediate expiry of timers.
But this does not help for time jumps in name spaces because the timer is
enqueued on the host time base.
And no, we should not think about creating per name space hrtimer queues
and then have to walk through all of them for finding the first expiring
timer in order to arm the hardware. That cannot scale.
Walking all hrtimer bases on all CPUs and check all queued timers whether
they belong to the affected name space does not scale either.
So we'd need to keep track of queued timers belonging to a name space and
then just handle them. Interesting locking problem and also a scalability
issue because this might need to be done on all online CPUs. Haven't
thought it through, but it makes me shudder.
I see two fundamental driving cases for a time namespace.
<SNIP>
I completely understand the problem you are trying to solve and yes, the
read out of time should be a solvable problem.
For timers my inclination would be to assume no adjustments to the
current time parameters and set the timer to go off then. If the time
on the appropriate clock has been changed since the timer was set and
the timer is going off early reschedule so the timer fires at the
appropriate time.
See above.
Not that I think a final implementation would necessary look like what I
have described. I just think it is possible with extreme care to evolve
the current code base into something that can efficiently handle
multiple time domains with slightly different lenghts of second.
Yes, it really needs some serious thoughts and timekeeping is a really
complex place especially with NTP/PTP in play. We had quite some quality
time to make it work correctly and reliably, now you come along and want to
transform it into a multidimensional puzzle. :)
Thomas does it sound like I am completely out of touch with reality?
Which reality are you talking about? :)
It does though sound like it is going to take some serious digging
through the code to understand how what everything does and how and why
everthing works the way it does. Not something grafted on top with just
a cursory understanding of how the code works.
I fully agree and I'm happy to help with explanations and ideas and being
the one who shoots holes into yours.
Thanks,
tglx
From: Andrei Vagin <hidden> Date: 2018-10-21 01:41:34
On Fri, Sep 28, 2018 at 07:03:22PM +0200, Eric W. Biederman wrote:
Thomas Gleixner [off-list ref] writes:
quoted
On Wed, 26 Sep 2018, Eric W. Biederman wrote:
quoted
Reading the code the calling sequence there is:
tick_sched_do_timer
tick_do_update_jiffies64
update_wall_time
timekeeping_advance
timekeepging_update
If I read that properly under the right nohz circumstances that update
can be delayed indefinitely.
So I think we could prototype a time namespace that was per
timekeeping_update and just had update_wall_time iterate through
all of the time namespaces.
Please don't go there. timekeeping_update() is already heavy and walking
through a gazillion of namespaces will just make it horrible,
quoted
I don't think the naive version would scale to very many time
namespaces.
:)
quoted
At the same time using the techniques from the nohz work and a little
smarts I expect we could get the code to scale.
You'd need to invoke the update when the namespace is switched in and
hasn't been updated since the last tick happened. That might be doable, but
you also need to take the wraparound constraints of the underlying
clocksources into account, which again can cause walking all name spaces
when they are all idle long enough.
The wrap around constraints being how long before the time sources wrap
around so you have to read them once per wrap around? I have not dug
deeply enough into the code to see that yet.
quoted
From there it becomes hairy, because it's not only timekeeping,
i.e. reading time, this is also affecting all timers which are armed from a
namespace.
That gets really ugly because when you do settimeofday() or adjtimex() for
a particular namespace, then you have to search for all armed timers of
that namespace and adjust them.
The original posix timer code had the same issue because it mapped the
clock realtime timers to the timer wheel so any setting of the clock caused
a full walk of all armed timers, disarming, adjusting and requeing
them. That's horrible not only performance wise, it's also a locking
nightmare of all sorts.
Add time skew via NTP/PTP into the picture and you might have to adjust
timers as well, because you need to guarantee that they are not expiring
early.
I haven't looked through Dimitry's patches yet, but I don't see how this
can work at all without introducing subtle issues all over the place.
Then it sounds like this will take some more digging.
Please pardon me for thinking out load.
There are one or more time sources that we use to compute the time
and for each time source we have a conversion from ticks of the
time source to nanoseconds.
Each time source needs to be sampled at least once per wrap-around
and something incremented so that we don't loose time when looking
at that time source.
There are several clocks presented to userspace and they all share the
same length of second and are all fundamentally offsets from
CLOCK_MONOTONIC.
I see two fundamental driving cases for a time namespace.
1) Migration from one node to another node in a cluster in almost
real time.
The problem is that CLOCK_MONOTONIC between nodes in the cluster
has not relation ship to each other (except a synchronized length of
the second). So applications that migrate can see CLOCK_MONOTONIC
and CLOCK_BOOTTIME go backwards.
This is the truly pressing problem and adding some kind of offset
sounds like it would be the solution. Possibly by allowing a boot
time synchronization of CLOCK_BOOTTIME and CLOCK_MONOTONIC.
2) Dealing with two separate time management domains. Say a machine
that needes to deal with both something inside of google where they
slew time to avoid leap time seconds and something in the outside
world proper UTC time is kept as an offset from TAI with the
occasional leap seconds.
In the later case it would fundamentally require having seconds of
different length.
I want to add that the second case should be optional.
When a container is migrated to another host, we have to restore its
monotonic and boottime clocks, but we still expect that the container
will continue using the host real-time clock.
Before stating this series, I was thinking about this, I decided that
these cases can be solved independently. Probably, the full isolation of
the time sub-system will have much higher overhead than just offsets for
a few clocks. And the idea that isolation of the real-time clock should
be optional gives us another hint that offsets for monotonic and
boot-time clocks can be implemented independently.
Eric and Tomas, what do you think about this? If you agree that these
two cases can be implemented separately, what should we do with this
series to make it ready to be merged?
I know that we need to:
* look at device drivers that report timestamps in CLOCK_MONOTONIC base.
* forbid changing offsets after creating timers
Anything else?
Thanks,
Andrei
A pure 64bit nanoseond counter is good for 500 years. So 64bit
variables can be used to hold time, and everything can be converted from
there.
This suggests we can for ticks have two values.
- The number of ticks from the time source.
- The number of times the ticks would have rolled over.
That sounds like it may be a little simplistic as it would require being
very diligent about firing a timer exactly at rollover and not losing
that, but for a handwaving argument is probably enough to generate
a 64bit tick counter.
If the focus is on a 64bit tick counter then what update_wall_time
has to do is very limited. Just deal the accounting needed to cope with
tick rollover.
Getting the actual time looks like it would be as simple as now, with
perhaps an extra addition to account for the number of times the tick
counter has rolled over. With limited precision arithmetic and various
optimizations I don't think it is that simple to implement but it feels
like it should be very little extra work.
For timers my inclination would be to assume no adjustments to the
current time parameters and set the timer to go off then. If the time
on the appropriate clock has been changed since the timer was set and
the timer is going off early reschedule so the timer fires at the
appropriate time.
With the above I think it is theoretically possible to build a time
namespace that supports multiple lengths of second, and does not have
much overhead.
Not that I think a final implementation would necessary look like what I
have described. I just think it is possible with extreme care to evolve
the current code base into something that can efficiently handle
multiple time domains with slightly different lenghts of second.
Thomas does it sound like I am completely out of touch with reality?
It does though sound like it is going to take some serious digging
through the code to understand how what everything does and how and why
everthing works the way it does. Not something grafted on top with just
a cursory understanding of how the code works.
Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
From: Andrei Vagin <hidden> Date: 2018-10-21 03:54:43
On Sat, Oct 20, 2018 at 06:41:23PM -0700, Andrei Vagin wrote:
On Fri, Sep 28, 2018 at 07:03:22PM +0200, Eric W. Biederman wrote:
quoted
Thomas Gleixner [off-list ref] writes:
quoted
On Wed, 26 Sep 2018, Eric W. Biederman wrote:
quoted
Reading the code the calling sequence there is:
tick_sched_do_timer
tick_do_update_jiffies64
update_wall_time
timekeeping_advance
timekeepging_update
If I read that properly under the right nohz circumstances that update
can be delayed indefinitely.
So I think we could prototype a time namespace that was per
timekeeping_update and just had update_wall_time iterate through
all of the time namespaces.
Please don't go there. timekeeping_update() is already heavy and walking
through a gazillion of namespaces will just make it horrible,
quoted
I don't think the naive version would scale to very many time
namespaces.
:)
quoted
At the same time using the techniques from the nohz work and a little
smarts I expect we could get the code to scale.
You'd need to invoke the update when the namespace is switched in and
hasn't been updated since the last tick happened. That might be doable, but
you also need to take the wraparound constraints of the underlying
clocksources into account, which again can cause walking all name spaces
when they are all idle long enough.
The wrap around constraints being how long before the time sources wrap
around so you have to read them once per wrap around? I have not dug
deeply enough into the code to see that yet.
quoted
From there it becomes hairy, because it's not only timekeeping,
i.e. reading time, this is also affecting all timers which are armed from a
namespace.
That gets really ugly because when you do settimeofday() or adjtimex() for
a particular namespace, then you have to search for all armed timers of
that namespace and adjust them.
The original posix timer code had the same issue because it mapped the
clock realtime timers to the timer wheel so any setting of the clock caused
a full walk of all armed timers, disarming, adjusting and requeing
them. That's horrible not only performance wise, it's also a locking
nightmare of all sorts.
Add time skew via NTP/PTP into the picture and you might have to adjust
timers as well, because you need to guarantee that they are not expiring
early.
I haven't looked through Dimitry's patches yet, but I don't see how this
can work at all without introducing subtle issues all over the place.
Then it sounds like this will take some more digging.
Please pardon me for thinking out load.
There are one or more time sources that we use to compute the time
and for each time source we have a conversion from ticks of the
time source to nanoseconds.
Each time source needs to be sampled at least once per wrap-around
and something incremented so that we don't loose time when looking
at that time source.
There are several clocks presented to userspace and they all share the
same length of second and are all fundamentally offsets from
CLOCK_MONOTONIC.
I see two fundamental driving cases for a time namespace.
1) Migration from one node to another node in a cluster in almost
real time.
The problem is that CLOCK_MONOTONIC between nodes in the cluster
has not relation ship to each other (except a synchronized length of
the second). So applications that migrate can see CLOCK_MONOTONIC
and CLOCK_BOOTTIME go backwards.
This is the truly pressing problem and adding some kind of offset
sounds like it would be the solution. Possibly by allowing a boot
time synchronization of CLOCK_BOOTTIME and CLOCK_MONOTONIC.
2) Dealing with two separate time management domains. Say a machine
that needes to deal with both something inside of google where they
slew time to avoid leap time seconds and something in the outside
world proper UTC time is kept as an offset from TAI with the
occasional leap seconds.
In the later case it would fundamentally require having seconds of
different length.
I want to add that the second case should be optional.
When a container is migrated to another host, we have to restore its
monotonic and boottime clocks, but we still expect that the container
will continue using the host real-time clock.
Before stating this series, I was thinking about this, I decided that
these cases can be solved independently. Probably, the full isolation of
the time sub-system will have much higher overhead than just offsets for
a few clocks. And the idea that isolation of the real-time clock should
be optional gives us another hint that offsets for monotonic and
boot-time clocks can be implemented independently.
Eric and Tomas, what do you think about this? If you agree that these
Sorry Thomas, I mistyped your name.
two cases can be implemented separately, what should we do with this
series to make it ready to be merged?
I know that we need to:
* look at device drivers that report timestamps in CLOCK_MONOTONIC base.
* forbid changing offsets after creating timers
Anything else?
Thanks,
Andrei
quoted
A pure 64bit nanoseond counter is good for 500 years. So 64bit
variables can be used to hold time, and everything can be converted from
there.
This suggests we can for ticks have two values.
- The number of ticks from the time source.
- The number of times the ticks would have rolled over.
That sounds like it may be a little simplistic as it would require being
very diligent about firing a timer exactly at rollover and not losing
that, but for a handwaving argument is probably enough to generate
a 64bit tick counter.
If the focus is on a 64bit tick counter then what update_wall_time
has to do is very limited. Just deal the accounting needed to cope with
tick rollover.
Getting the actual time looks like it would be as simple as now, with
perhaps an extra addition to account for the number of times the tick
counter has rolled over. With limited precision arithmetic and various
optimizations I don't think it is that simple to implement but it feels
like it should be very little extra work.
For timers my inclination would be to assume no adjustments to the
current time parameters and set the timer to go off then. If the time
on the appropriate clock has been changed since the timer was set and
the timer is going off early reschedule so the timer fires at the
appropriate time.
With the above I think it is theoretically possible to build a time
namespace that supports multiple lengths of second, and does not have
much overhead.
Not that I think a final implementation would necessary look like what I
have described. I just think it is possible with extreme care to evolve
the current code base into something that can efficiently handle
multiple time domains with slightly different lenghts of second.
Thomas does it sound like I am completely out of touch with reality?
It does though sound like it is going to take some serious digging
through the code to understand how what everything does and how and why
everthing works the way it does. Not something grafted on top with just
a cursory understanding of how the code works.
Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
From: Thomas Gleixner <hidden> Date: 2018-10-29 20:33:27
Andrei,
On Sat, 20 Oct 2018, Andrei Vagin wrote:
When a container is migrated to another host, we have to restore its
monotonic and boottime clocks, but we still expect that the container
will continue using the host real-time clock.
Before stating this series, I was thinking about this, I decided that
these cases can be solved independently. Probably, the full isolation of
the time sub-system will have much higher overhead than just offsets for
a few clocks. And the idea that isolation of the real-time clock should
be optional gives us another hint that offsets for monotonic and
boot-time clocks can be implemented independently.
Eric and Tomas, what do you think about this? If you agree that these
two cases can be implemented separately, what should we do with this
series to make it ready to be merged?
I know that we need to:
* look at device drivers that report timestamps in CLOCK_MONOTONIC base.
and CLOCK_BOOTTIME and that's quite a few.
* forbid changing offsets after creating timers
There are more things to think about. What about interfaces which expose
boot time or monotonic time in /proc?
Aside of that (I finally came around to look at the series in more detail)
I'm really unhappy about the unconditional overhead once the Time namespace
config switch is enabled. This applies especially to the VDSO. We spent
quite some time recently to squeeze a few cycles out of those functions and
it would be a pity to pointlessly waste cycles for the !namespace case.
I can see the urge for this, but please let us think it through properly
before rushing anything in which we are going to regret once we want to do
more sophisticated time domain management, e.g. support for isolated clock
real time. I'm worried, that without a clear plan about the overall
picture, we end up with duct tape which is hard to distangle after the
fact.
There have been a few other things brought up versus time management in
general, like the TSN folks utilizing grand clock masters which expose
random time instead of proper TAI. Plus some requirements for exposing some
sort of 'monotonic' clocks which are derived from external synchronization
mechanisms, but should not affect the regular time keeping clocks.
While different issues, these all fall into the category of separate time
domains, so taking a step back to the drawing board is probably the best
thing what we can do now.
There are certainly a few things which can be looked at independently,
e.g. the VDSO mechanics or general mechanisms to avoid plastering the whole
kernel with these name space functions applying offsets left and right. I
rather have dedicated core functionality which replaces/amends existing
timer functions to become time namespace aware.
I'll try to find some time in the next weeks to look deeper into that, but
I can't promise anything before returning from LPC. Btw, LPC would be a
great opportunity to discuss that. Are you and the other name space wizards
there by any chance?
Thanks,
tglx
From: Andrei Vagin <hidden> Date: 2018-10-31 16:27:00
On Mon, Oct 29, 2018 at 09:33:14PM +0100, Thomas Gleixner wrote:
Andrei,
On Sat, 20 Oct 2018, Andrei Vagin wrote:
quoted
When a container is migrated to another host, we have to restore its
monotonic and boottime clocks, but we still expect that the container
will continue using the host real-time clock.
Before stating this series, I was thinking about this, I decided that
these cases can be solved independently. Probably, the full isolation of
the time sub-system will have much higher overhead than just offsets for
a few clocks. And the idea that isolation of the real-time clock should
be optional gives us another hint that offsets for monotonic and
boot-time clocks can be implemented independently.
Eric and Tomas, what do you think about this? If you agree that these
two cases can be implemented separately, what should we do with this
series to make it ready to be merged?
I know that we need to:
* look at device drivers that report timestamps in CLOCK_MONOTONIC base.
and CLOCK_BOOTTIME and that's quite a few.
quoted
* forbid changing offsets after creating timers
There are more things to think about. What about interfaces which expose
boot time or monotonic time in /proc?
We didn't find any proc files where boot or monotonic time is reported,
but we will double check this.
Aside of that (I finally came around to look at the series in more detail)
I'm really unhappy about the unconditional overhead once the Time namespace
config switch is enabled. This applies especially to the VDSO. We spent
quite some time recently to squeeze a few cycles out of those functions and
it would be a pity to pointlessly waste cycles for the !namespace case.
It is a good point. We will work on it.
I can see the urge for this, but please let us think it through properly
before rushing anything in which we are going to regret once we want to do
more sophisticated time domain management, e.g. support for isolated clock
real time. I'm worried, that without a clear plan about the overall
picture, we end up with duct tape which is hard to distangle after the
fact.
Thomas, there is no rush at all. This functionality is critical for
CRUI, but we have enough time to solve it properly.
The only thing what I want is that this functionality continues moving
forward and will not be put in the back burner.
There have been a few other things brought up versus time management in
general, like the TSN folks utilizing grand clock masters which expose
random time instead of proper TAI. Plus some requirements for exposing some
sort of 'monotonic' clocks which are derived from external synchronization
mechanisms, but should not affect the regular time keeping clocks.
While different issues, these all fall into the category of separate time
domains, so taking a step back to the drawing board is probably the best
thing what we can do now.
There are certainly a few things which can be looked at independently,
e.g. the VDSO mechanics or general mechanisms to avoid plastering the whole
kernel with these name space functions applying offsets left and right. I
rather have dedicated core functionality which replaces/amends existing
timer functions to become time namespace aware.
I'll try to find some time in the next weeks to look deeper into that, but
I can't promise anything before returning from LPC. Btw, LPC would be a
great opportunity to discuss that. Are you and the other name space wizards
there by any chance?
Dmitry and I are going to be there.
Thanks!
Andrei