Re: Understanding PR kern/43997 (kernel timing problems / qemu)

Date:Sun, 30 Jul 2017 16:04:38 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | There are slower emulated systems that don't have these issues. (*) Yes, that it is not qemu's execution speed was (really, always)

Re: kmem_alloc(0, f)

On Sun, Jul 30, 2017 at 03:23:50PM -, Michael van Elst wrote: > So what does kmem_alloc(0, KM_SLEEP) do? fail where KM_SLEEP says it > cannot fail? I don't think that it can return a zero sized allocation > (i.e. ptr != NULL that cannot be dereferenced). Sure it could, return a pointer inside

Re: kmem API to allocate arrays

On Sun, Jul 30, 2017 at 03:30:59PM -, Michael van Elst wrote: > Reallocation is usually a reason for memory fragmentation. I would > rather try to avoid it instead of making it easier. Agreeed. Also for kernel drivers, resizing an array allocation is a very rare operation and no good reason

Re: Understanding PR kern/43997 (kernel timing problems / qemu)

g...@gson.org (Andreas Gustafsson) writes: >Frank Kardel wrote: >> Fixing that requires some more work. But I am surprised that the qemu >> interrupt rate is seemingly somewhat around 50Hz. It shouldn't have a problem on Linux. -- -- Michael van Elst Internet:

Re: kmem API to allocate arrays

On 30.07.2017 16:51, Taylor R Campbell wrote: >> Date: Sun, 30 Jul 2017 16:24:07 +0200 >> From: Kamil Rytarowski >> >> I would allow size to be 0, like with the original reallocarr(3). It >> might be less pretty, but more compatible with the original model and >> less vulnerable to

Re: kmem API to allocate arrays

campbell+netbsd-tech-k...@mumble.net (Taylor R Campbell) writes: >Initially I was reluctant to do that because (a) we don't even have a >kmem_realloc, perhaps for some particular reason, and (b) it requires >an extra parameter for the old size. But I don't know any particular >reason in (a), and

Re: kmem_alloc(0, f)

mar...@duskware.de (Martin Husemann) writes: >On Sat, Jul 29, 2017 at 02:04:42PM +, Taylor R Campbell wrote: >> This seems like a foot-oriented panic gun, and it's been a source of >> problems in the past. Can we change it? >I think it is a valuable tool to catch driver bugs early during

Re: Understanding PR kern/43997 (kernel timing problems / qemu)

>> # time sleep 10 >>10.02 real 0.00 user 0.00 sys >> This actually took 20 seconds of real time (manually timed with a >> stopwatch). > [...], but an error of a factor 2 looks suspicious. This is tickling old memories. I think I ran into a case where requesting timer

Re: kmem API to allocate arrays

> Date: Sun, 30 Jul 2017 16:24:07 +0200 > From: Kamil Rytarowski > > I would allow size to be 0, like with the original reallocarr(3). It > might be less pretty, but more compatible with the original model and > less vulnerable to accidental panics for no good reason. Hard to

Re: kmem API to allocate arrays

On 30.07.2017 15:45, Taylor R Campbell wrote: >> Date: Sun, 30 Jul 2017 10:22:11 +0200 >> From: Kamil Rytarowski >> >> I think we should go for kmem_reallocarr(). It has been designed for >> overflows like realocarray(3) with an option to be capable to resize a >> table fron 1 to N

Re: Understanding PR kern/43997 (kernel timing problems / qemu)

Frank Kardel wrote: > Fixing that requires some more work. But I am surprised that the qemu > interrupt rate is seemingly somewhat around 50Hz. > Could it be a bug in qemu getting the frequeny not right. qemu should > read the clock to get the frequencies right an possibly skip > usleeps less

Re: kmem API to allocate arrays

> Date: Sun, 30 Jul 2017 10:22:11 +0200 > From: Kamil Rytarowski > > I think we should go for kmem_reallocarr(). It has been designed for > overflows like realocarray(3) with an option to be capable to resize a > table fron 1 to N elements and back from N to 0 including freeing.

Re: Understanding PR kern/43997 (kernel timing problems / qemu)

Hi Andreas ! On 07/30/17 15:20, Andreas Gustafsson wrote: > Frank Kardel wrote: >> Could you check which timecounter is used under qemu? >> >> sysctl kern.timecounter.hardware > > # sysctl kern.timecounter.hardware > kern.timecounter.hardware = hpet0 > >> Usually the timecounters are

Re: Understanding PR kern/43997 (kernel timing problems / qemu)

Could you check which timecounter is used under qemu? sysctl kern.timecounter.hardware Usually the timecounters are hardware-based and have no relation to the clockinterrupt. In case of qemu you might get a good emulated timecounter, but a suboptimal clockinterupt. If this is the case it helps

Re: Understanding PR kern/43997 (kernel timing problems / qemu)

Date:Sun, 30 Jul 2017 13:01:50 +0300 From:Andreas Gustafsson Message-ID: <22909.44686.188004.117...@guava.gson.org> | I don't think the slowness of qemu's emulation is the actual cause of | its inability to simulate clock interrupts at 100 Hz.

Re: kmem_alloc(0, f)

On Sat, Jul 29, 2017 at 02:04:42PM +, Taylor R Campbell wrote: > This seems like a foot-oriented panic gun, and it's been a source of > problems in the past. Can we change it? I think it is a valuable tool to catch driver bugs early during developement, but wouldn't mind to reduce it to a

Re: Understanding PR kern/43997 (kernel timing problems / qemu)

Robert Elz wrote: > I want to leave /bin/sh to percolate for a while, make sure there are > no issues with it as it is, before starting on the next round of > cleanups and bug fixes, so I was looking for something else to poke > my nose into ... > > [Aside: the people I added to the cc of this

Understanding PR kern/43997 (kernel timing problems / qemu)

I want to leave /bin/sh to percolate for a while, make sure there are no issues with it as it is, before starting on the next round of cleanups and bug fixes, so I was looking for something else to poke my nose into ... [Aside: the people I added to the cc of this message are those who have