Re: tickless kernel - high level roadmap ideas
> On Wed, 10 Apr 2024 12:37:31 +, Ice Cream > said: >> I've been working a little bit on how to tackle tickless in the >> kernel. I'll be hoping to send some preliminary patches later this month >> or so - so this is mostly an email to co-ordinate with anyone else >> working or aiming to work on similar things. > Hi, I'm aiming to work on this project as well. >> One of the first things needed will be to discover and manage underlying >> hardware timers which can interrupt at arbitrary (and/or repetitive) >> timeouts. Therefore, one of the first things I'll be working on is how >> to abstract this management. Since we need to support a variety of >> platform/CPU/CPU-package configurations, this will be the part with a >> large number of cross platform dependencies. > Since you'll be working on this, I'll start with researching about the next > step, > that is, the callout variants using bintime and the usage of the new timer > API. Brilliant! Let's take the details offline, so that we don't spam the list. I'll email you separately. -- Math/(~cherry)
Re: tickless kernel - high level roadmap ideas
> I've been working a little bit on how to tackle tickless in the > kernel. I'll be hoping to send some preliminary patches later this month > or so - so this is mostly an email to co-ordinate with anyone else > working or aiming to work on similar things. Hi, I'm aiming to work on this project as well. > One of the first things needed will be to discover and manage underlying > hardware timers which can interrupt at arbitrary (and/or repetitive) > timeouts. Therefore, one of the first things I'll be working on is how > to abstract this management. Since we need to support a variety of > platform/CPU/CPU-package configurations, this will be the part with a > large number of cross platform dependencies. Since you'll be working on this, I'll start with researching about the next step, that is, the callout variants using bintime and the usage of the new timer API. -- IC
tickless kernel - high level roadmap ideas
Hello NetBSD, I've been working a little bit on how to tackle tickless in the kernel. I'll be hoping to send some preliminary patches later this month or so - so this is mostly an email to co-ordinate with anyone else working or aiming to work on similar things. The only discernable change from an API consumption perspective for the rest of the kernel would be the appearance of bintime(9) variants of callout(9). Functionally, when tickless is enabled finally, any APIs which depend on sleep/wakeup semantics will have finer than 1/hz granularity. I can't think of any other discernable consumer facing changes at this point - feel free to mention them. To implement tickless however, things under the hood will need to change quite a bit. One of the first things needed will be to discover and manage underlying hardware timers which can interrupt at arbitrary (and/or repetitive) timeouts. Therefore, one of the first things I'll be working on is how to abstract this management. Since we need to support a variety of platform/CPU/CPU-package configurations, this will be the part with a large number of cross platform dependencies. Once this API is in place, the callout variants using bintime, described above, will need to be enabled to use this timer API in order to provide sub 1/hz granularity. Finally, consumers such as sleep/wakeup providers (cv_timedwaitbt(9), kpause(9) etc) and a whole bunch of other functions which depend upwards on these and others will need to be enabled to use the new sub 1/hz callout APIs. >From my initial experiments, and discussions with core@ , it looks like all this can be done mostly without changing the current hardclock(9) semantics - those semantics can simply be converted to use the new timer management API described above. Finally, the system time model can be updated to use high-res timers - I won't go into detail here, because it's a bit premature to speculate what that might look like - there seem to be a bunch of dependencies, including into CSF(9), softint(9), heartbeat(9), and anything that polls for timestamp updates (eg: timecounter(9) ). Looking forward to your comments and thoughts. Best, -- Math/(~cherry)
Re: Tickless kernel
On Mon, Jul 03, 2017 at 02:03:32AM +, m...@netbsd.org wrote: > On Sun, Jul 02, 2017 at 11:10:19PM -, Michael van Elst wrote: > > it needs MD support on all platforms. > > What more does an implementation need besides asking for an interrupt in > timo at cv_timedwait* (and increasing HZ)? Removal of HZ... -- David A. Holland dholl...@netbsd.org
Re: Tickless kernel
On Mon, Jul 03, 2017 at 06:29:35AM -, Michael van Elst wrote: > For a tickless kernel you need a one-shot timer instead that > can be armed to fire at an arbitrary time. Optionally you could > tell it to fire on a specific CPU. I think the system nanotime has to be in sync with this timer. Also, you must be able to abort the current timing cycle and schedule an interrupt that occurs sooner than the one that was ticking. Not difficult on software side if the hardware supports these things. -jm
Re: Tickless kernel
On Mon, Jul 03, 2017 at 06:29:35AM -, Michael van Elst wrote: > For a tickless kernel you need a one-shot timer instead that > can be armed to fire at an arbitrary time. Optionally you could > tell it to fire on a specific CPU. Let's define a kernel API and a __HAVE_MD_TICKLESS_SUPPORT (or some better name) and move individual architectures over when they are ready! Martin
Re: Tickless kernel
m...@netbsd.org writes: >On Sun, Jul 02, 2017 at 11:10:19PM -, Michael van Elst wrote: >> it needs MD support on all platforms. >What more does an implementation need besides asking for an interrupt in >timo at cv_timedwait* (and increasing HZ)? >That could be a no-op for platforms that can't provide it. Currently the platform provides the regular hardclock interrupt that dispatches all timed activity. For a tickless kernel you need a one-shot timer instead that can be armed to fire at an arbitrary time. Optionally you could tell it to fire on a specific CPU. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Tickless kernel
On Sun, Jul 02, 2017 at 11:10:19PM -, Michael van Elst wrote: > it needs MD support on all platforms. What more does an implementation need besides asking for an interrupt in timo at cv_timedwait* (and increasing HZ)? That could be a no-op for platforms that can't provide it.
