Re: nanosleep() for shorted than schedule slice
b...@softjar.se (Johnny Billquist) writes: >On 2017-07-03 07:25, Michael van Elst wrote: >> b...@softjar.se (Johnny Billquist) writes: >> >>> Having the normal wall clock driven by a tick interrupt has its points. >> >> We usually avoid this and use what hardware timer the platform offers. >Which is the HZ interrupt, It's usually not the HZ interrupt, but you can chose kern.timecounter.choice = clockinterrupt as a fallback. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: nanosleep() for shorted than schedule slice
On 2017-07-03 07:25, Michael van Elst wrote: b...@softjar.se (Johnny Billquist) writes: Having the normal wall clock driven by a tick interrupt has its points. We usually avoid this and use what hardware timer the platform offers. Which is the HZ interrupt, unless I'm confused. And that drives the wall clock, with all the additional bells and whistles of clock adjustments to make sure the clock normally is monotonic, and is just the number of seconds since epoch. It's just that for high resolution timers, ticks are not a good source. For anything else, they are just fine. So why conflate the two? Because you don't need two clock interrupts. The regular interrupt is just another event that happens to be scheduled in a regular interval. Right. It would mean having two clock interrupts. Need and need. There are lots of things you don't need, but which might make things more convenient. But, as I said before, I won't object to any implementation. I was just objecting to the argument that tickless was a requirement for getting high precision timers, which it is not. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: Go on NetBSD needs love
In article <20170702202656.gc29...@netbsd.org>, David Holland wrote: >On Fri, Jun 30, 2017 at 07:36:41PM +0200, Joerg Sonnenberger wrote: > > From the follow-up, it is far from clear that it is fixed completely. > >Yes, I was wondering about that but people have been saying it works >on -8... > > > I'm running current with https://www.netbsd.org/~joerg/kern_event.c.diff > > with the go 1.8.3 test suite in an infinite loop. Modulo the Perl 5.26.0 > > issue in vet_test and some occassional time outs from individual tests, > > I don't see any issues. > >any reason not to commit? Go needs two commits to work which are already in current: For 8: https://releng.netbsd.org/cgi-bin/req-8.cgi?show=91 For 7: https://releng.netbsd.org/cgi-bin/req-7.cgi?show=1442 christos
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: resize_ffs and ufs2
On Mon, Jul 03, 2017 at 09:15:54AM -0400, Chris Humphries wrote: > Working with coypu and interested in kernel development, with filesystems > and data storage in particular, I was pointed to resize_ffs and shrinking > ufs2 support (PR #44205 and in src/sbin/resize_ffs/TODO). > > My question is before I get started, are there things a newbie like me > should know before I boldly plow into the code of ufs2 and resize_ffs > deeper? Want to be sure I at least check if there is tribal or expert > knowledge on the challenges of this task before rediscovering the wheel. I have no idea what's wrong with resize_ffs shrinking ffsv2, but one of the significant differences between ffsv1 and ffsv2 is that in ffsv2 inodes are not zeroed out in advance by newfs; instead there's a thing that keeps track of which ones have been zeroed and which ones still need to be. Manipulating that correctly was what was missing from growing ffsv2 volumes at one point. Also mind PR 44204, but it is probably not closely related. -- David A. Holland dholl...@netbsd.org
Re: resize_ffs and ufs2
>> My question is before I get started, are there things a newbie like >> me should know before I boldly plow into the code of ufs2 and >> resize_ffs deeper? > No doubt there is various tribal knowledge! However, such knowledge > usually manifests in the form of answering questions than in the form > of a prewritten document you can read ahead of time. As the author of the program that resize_ffs started life as, I'm certainly up for talking about this stuff. Much of the knowledge, though, is embedded in comments in the code, most of which made it through the porting effort into resize_ffs.c; it might be worth a read-through. However, I didn't see your message - only a reply to it - so there was presumably something about it that made my mailer reject it (looking at what evidence I see, my best guess is, it was sent through gmail). If you want to write to me about it, and you have some other sending path, either mo...@netbsd.org or the address below might be worth a try. Of course, I'm hardly the only person who knows FFS. There are a bunch of other people competent to have written fsresize (the program which got ported to become resize_ffs); I'm just the one who actually did. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: resize_ffs and ufs2
> Date: Mon, 3 Jul 2017 09:15:54 -0400 > From: Chris Humphries > > My question is before I get started, are there things a newbie like me > should know before I boldly plow into the code of ufs2 and resize_ffs > deeper? Want to be sure I at least check if there is tribal or expert > knowledge on the challenges of this task before rediscovering the wheel. No doubt there is various tribal knowledge! However, such knowledge usually manifests in the form of answering questions than in the form of a prewritten document you can read ahead of time. You may find the documentation in src/share/doc/smm/05.fastfs/ and src/sbin/fsck_ffs/SMM.doc/ useful -- although I'm not sure it has any information about changes in the ufs2/ffsv2 format, and there's separate `v2' for the superblock format and the rest of the file system format.
resize_ffs and ufs2
Hello, Working with coypu and interested in kernel development, with filesystems and data storage in particular, I was pointed to resize_ffs and shrinking ufs2 support (PR #44205 and in src/sbin/resize_ffs/TODO). My question is before I get started, are there things a newbie like me should know before I boldly plow into the code of ufs2 and resize_ffs deeper? Want to be sure I at least check if there is tribal or expert knowledge on the challenges of this task before rediscovering the wheel. Thank you, Chris -- Chris Humphries PGP: 6338DD29 ch...@sogubsys.com
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