Re: nanosleep() for shorted than schedule slice

2017-07-03 Thread Michael van Elst 
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

2017-07-03 Thread Johnny Billquist 



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

2017-07-03 Thread Christos Zoulas 
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

2017-07-03 Thread David Holland 
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

2017-07-03 Thread David Holland 
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

2017-07-03 Thread Taylor R Campbell 
> 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

2017-07-03 Thread Chris Humphries 
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

2017-07-03 Thread Jukka Marin 
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

2017-07-03 Thread Martin Husemann 
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: nanosleep() for shorted than schedule slice

2017-07-03 Thread Frank Kardel 



On 07/03/17 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.

Basically yes, but as these timers wrap after a while we need to 
checkpoint (call tc_windup() often enough)
the hw counters at at least twice the wrapping frequency.. It is not 
magic either, but needs some care handling

to keep our monotonic- and wall-clock- time keeping and NTP happy.

If I remember correctly FreeBSD already made the step to tickless, last 
time I looked.

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.




Frank

Re: Tickless kernel

2017-07-03 Thread Michael van Elst 
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."