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.
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."
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
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 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
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 - 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
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)
[GSoC 2019] Tentative interest in the tickless kernel project
Hello, I am a student, and am strongly considering participating in Google Summer of Code for the following summer. I know a NetBSD developer, so I am interested in contributing to NetBSD. First, some background about me: I have been programming in C for about 4 years. I started programming in open source projects, so I understand some of the etiquette which is common between them. For example, I worked quite a bit on some of Drew DeVault's C projects, such as Sway[0]; I have contributed a patch to QEMU; and I have worked on various projects in Rust, culminating in my kernel[1]. I have experience with communicating through email and IRC, but less so with using version control systems like `cvs` and `hg` (but I have used git and email based workflows to a larger extent). Furthermore, I have little direct experience with NetBSD, even though I have done hobby kernel development (including writing a scheduler) on my own. This is why I wanted to reach out: I am very interested in the "Tickless NetBSD with high-resolution timers"[2] project, however I am not sure if I have the necessary experience to complete all of the milestones listed. If I were to work on this project, I would have to spend some time getting used to the NetBSD kernel, since the project touches many aspects of it. So, if this is an acceptable project for me, I would like help finding resources on how to better know the kernel, especially the scheduler and other subsystems related to this project. Otherwise, I would appreciate if someone could point me toward another place where I could contribute. Either way, I am planning on sending an email to tech-userland concerning an easier project. If you would like to contact me outside of email, I am "pounce" on freenode and most other irc networks. Thank you, Calvin Lee [0]: https://swaywm.org/ (would probably not work on NetBSD due to Wayland not being cross platform) [1]: https://github.com/ESALP/ESALP-1 [2]: https://wiki.netbsd.org/projects/project/tickless/
