Re: Spinning time is not System time

On Wed, May 09, 2018 at 01:36:08PM +0200, Martin Pieuchot wrote: > On 08/05/18(Tue) 18:03, Martin Pieuchot wrote: > > Diff below, gypped from jmatthew@, allows us to see how much time CPUs > > spend spinning on a mutex or on the KERNEL_LOCK(). > > > > On my sparc64 with 16 CPUs, top(1) now

pf route to on loopback

Hi, I while ago I changed pf route-to that it does not send packets from 127.0.0.1 address to the network. This is necessary for localy generated icmp packets that would be dropped otherwise. Now I found out that this prevents some useful routing tricks on loopback. So this check should be

Re: Spinning time is not System time

On Wed, May 09, 2018 at 01:36:08PM +0200, Martin Pieuchot wrote: > > To keep it simple, systat(1) vmstat view now shows the spinning time instead > > of the nice time. Could the nice time added to user there? I interpret this line that the sum should be 100%. Anyway, that can be changed later.

Re: futex: FUTEX_WAIT: check for normalized timeout

On Wed, May 09, 2018 at 11:54:15AM +0300, Paul Irofti wrote: > On Wed, May 09, 2018 at 10:37:14AM +0200, Martin Pieuchot wrote: > > On 08/05/18(Tue) 14:57, Scott Cheloha wrote: > > > Hi, > > > > > > futex(2) doesn't do any range checking for timeout for FUTEX_WAIT, > > > though recent Linux does

Re: Spinning time is not System time

On Wed, May 09, 2018 at 01:36:08PM +0200, Martin Pieuchot wrote: > On 08/05/18(Tue) 18:03, Martin Pieuchot wrote: > > Diff below, gypped from jmatthew@, allows us to see how much time CPUs > > spend spinning on a mutex or on the KERNEL_LOCK(). > > > > On my sparc64 with 16 CPUs, top(1) now

mpfsafe pfkey socket list

Diff below turns the list of pfkey sockets into a SRPL. It reuses the logic introduced by claudio@ for routing sockets. That allows us to stop grabbing the KERNEL_LOCK() when iterating over the list. ok? Index: net/pfkeyv2.c ===

Re: Say no to LARVAL

Regress test on i386 pass with this larval diff. bluhm

Re: Spinning time is not System time

On 08/05/18(Tue) 18:03, Martin Pieuchot wrote: > Diff below, gypped from jmatthew@, allows us to see how much time CPUs > spend spinning on a mutex or on the KERNEL_LOCK(). > > On my sparc64 with 16 CPUs, top(1) now reports: > > 16 CPUs: 16.8% user, 0.0% nice, 9.2% sys, 49.4% spin, 0.1%

Re: [patch] Unify format of tcpbench man page

On Wed, May 09, 2018 at 04:26:54PM +0800, Nan Xiao wrote: > Hi tech@, > > This patch unifies format of tcpbench man page. Apologize if I am wrong, > thanks! > fixed, thanks. jmc > Index: tcpbench.1 > === > RCS file:

Re: new semapahore implementation using atomics and futexes

On 09/05/18(Wed) 13:07, Paul Irofti wrote: > On Wed, May 09, 2018 at 11:33:06AM +0200, Martin Pieuchot wrote: > > On 09/05/18(Wed) 11:43, Paul Irofti wrote: > > [...] > > Then the writer uses atomic operations to increment/decrement `waitcount' > > but is it enough to have the reader, see the

Re: Say no to LARVAL

On 08/05/18(Tue) 14:12, Philip Guenther wrote: > On Tue, 8 May 2018, Martin Pieuchot wrote: > > The way our kernel allocates and populates new 'struct file *' is > > currently a complete mess. One of the problems is that it puts > > incomplete descriptors on the global `filehead' list and on the

Re: new semapahore implementation using atomics and futexes

On Wed, May 09, 2018 at 11:33:06AM +0200, Martin Pieuchot wrote: > On 09/05/18(Wed) 11:43, Paul Irofti wrote: > > > [...] > > > I'm saying that increasing/decreasing `waitcount' now serves a single > > > purpose: the check in sem_destroy(). However with your implementation > > > this check is

Re: new semapahore implementation using atomics and futexes

On 09/05/18(Wed) 11:43, Paul Irofti wrote: > > [...] > > I'm saying that increasing/decreasing `waitcount' now serves a single > > purpose: the check in sem_destroy(). However with your implementation > > this check is racy and adds two atomic operation on top of every > > syscall. So my

Re: futex: FUTEX_WAIT: check for normalized timeout

On Wed, May 09, 2018 at 10:37:14AM +0200, Martin Pieuchot wrote: > On 08/05/18(Tue) 14:57, Scott Cheloha wrote: > > Hi, > > > > futex(2) doesn't do any range checking for timeout for FUTEX_WAIT, > > though recent Linux does so. I assume we'd also want to validate > > timeout before waiting. > >

Re: new semapahore implementation using atomics and futexes

> > > > new file mode 100644 > > > > index 000..e5c8015d27c > > > > --- /dev/null > > > > +++ lib/librthread/rthread_sem_atomic.c > > > > > > I'm not fan of the _atomic suffix. What about rthread_semaphore.c? > > > > I am not set on the name, but I do think rthread_semaphore is not a

Re: futex: FUTEX_WAIT: check for normalized timeout

On 08/05/18(Tue) 14:57, Scott Cheloha wrote: > Hi, > > futex(2) doesn't do any range checking for timeout for FUTEX_WAIT, > though recent Linux does so. I assume we'd also want to validate > timeout before waiting. Could you use timespecfix() for that? Look how pselect(2) or ppoll(2) do it.

[patch] Unify format of tcpbench man page

Hi tech@, This patch unifies format of tcpbench man page. Apologize if I am wrong, thanks! Index: tcpbench.1 === RCS file: /cvs/src/usr.bin/tcpbench/tcpbench.1,v retrieving revision 1.23 diff -u -p -r1.23 tcpbench.1 --- tcpbench.1

Re: in_ioctl(): hoist privilege check

On 09/05/18(Wed) 10:18, Theo Buehler wrote: > Currently the privilege checks in in_ioctl() happen rather late and for > SIOCAIFADDR and SIOCDIFADDR after a /* FALLTHROUGH */. As a further > small cleanup step in this function, I'd like to move this check to the > top. This way it's clearer from

in_ioctl(): hoist privilege check

Currently the privilege checks in in_ioctl() happen rather late and for SIOCAIFADDR and SIOCDIFADDR after a /* FALLTHROUGH */. As a further small cleanup step in this function, I'd like to move this check to the top. This way it's clearer from the start which ioctls are explicitly taken care of

Re: real-time Options compiling

On 2018/05/09 06:12, cheng wensui wrote: > This is real-time Linux Project > > Does openbsd have similar projects? > or When compiling source code have about "real-time" Options？？？ No.

real-time Options compiling

This is real-time Linux Project Does openbsd have similar projects? or When compiling source code have about "real-time" Options？？？