From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 28 Nov 2012 14:29:19 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: <20121128185827.863CFB827@mail.bitblocks.com> References: <0263c93c2d57900638e664f1b538a76d@brasstown.quanstro.net> <0cf8de222eb5fa81721e8bcf4dd4e875@brasstown.quanstro.net> <20121128185827.863CFB827@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] sleep(2) historical question Topicbox-Message-UUID: ec036840-ead7-11e9-9d60-3106f5b1d025 > > None of the applications look likely to need microsecond let alone > > nanosecond resolution, and that seems reasonable to me. > > One exception is sleep(0), but that's yield() >=20 > Chicken and egg. i think so. > > > None of the applications look likely to need microsecond let alone > > > nanosecond resolution, and that seems reasonable to me. > > > One exception is sleep(0), but that's yield() > >=20 > > you haven't explained how one can emulate a sub-ms > > sleep with the edf scheduler. i've got a legit problem. >=20 > Why not add nsleep() with sleeptime in nanosecond units? And > of course, any necessary kernel changes for better accuracy. as it turns out, for anything i had in mind, the kernel already can do about 10x what i need. i need maybe 500=C2=B5s, and i can get 50=C2=B5= s at 4% error. the only problem i see with just adding nsleep is it introduces a second time base, and potentially any time-based call (tsemacquire) would need to be doubled. i would prefer for the end state to be 1 user space time base. but the difficulty is getting there. at the least, the syscall# would change. > The whole idea of a kernel HZ clock seems a bit outdated now. > If the system has nothing do for the next N seconds, it should > may be go into low-power mode & just wait for an interrupt. and when you have things to do, the hz clock is just an unnecessary interruption. - erik