Re: workqueue_drain

On Thu, Dec 21, 2017 at 5:56 PM, Ryota Ozaki wrote: > On Thu, Dec 21, 2017 at 5:58 AM, Michael van Elst wrote: >> ozak...@netbsd.org (Ryota Ozaki) writes: >> >>>On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst wrote: What about a

Re: RFC: ipsec(4) pseudo interface

Hi, I'm sorry, I send mail while editing by mistake. On 2017/12/20 22:40, Thor Lancelot Simon wrote: > On Mon, Dec 18, 2017 at 06:49:44PM +0900, Kengo NAKAHARA wrote: >> Hi, >> >> We implement ipsec(4) pseudo interface for route-based VPNs. This pseudo >> interface manages its security

Re: RFC: ipsec(4) pseudo interface

Hi, Thank you for your reviewing. On 2017/12/20 21:08, Christos Zoulas wrote: > In article <75925357-8e16-0f0f-b7a0-78155c865...@iij.ad.jp>, > Kengo NAKAHARA wrote: >> Hi, >> >> On 2017/12/19 2:54, Christos Zoulas wrote: >>> In article

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

On Fri, Dec 22, 2017 at 11:33 AM, Ryota Ozaki <ozaki.ry...@gmail.com> wrote: > On Thu, Dec 21, 2017 at 7:45 PM, Frank Kardel <kar...@netbsd.org> wrote: >> Hi, >> >> does this panic (with -current/amd64 as of 20171221) ring a bell with >> anyone? > &

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

On Thu, Dec 21, 2017 at 7:58 PM, Nick Hudson wrote: > On 12/19/17 08:21, Ryota Ozaki wrote: >> >> On Tue, Dec 19, 2017 at 4:52 PM, Nick Hudson >> wrote: >>> >>> On 19/12/2017 03:43, Ryota Ozaki wrote: >>> >>> BTW I committed a change that disables

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

On Thu, Dec 21, 2017 at 7:45 PM, Frank Kardel <kar...@netbsd.org> wrote: > Hi, > > does this panic (with -current/amd64 as of 20171221) ring a bell with > anyone? Yes. Could you try the patch below? Thanks, ozaki-r diff --git a/sys/net/if.c b/sys/net/if.c index 05ac3b

Re: parallel (free) pagequeue

Summarising our IRC discussion: "someone" (aka joerg): hashing on paddrs is probably subpar, it's as much work but without balancing. the free pagequeue is a good first goal, and contention on it leads to contention on the non-free pagequeue too. frustrated we have per-CPU and global free page

parallel pagequeue

hi folks. I wonder why we are not using a hashed lock for uvm_pageqlock. (lock only some of the pages for most accesses). but someone called it a 'brute force' method. I can't think of a more sophisticated or clever thing to do. ideas?

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

On 12/19/17 08:21, Ryota Ozaki wrote: On Tue, Dec 19, 2017 at 4:52 PM, Nick Hudson wrote: On 19/12/2017 03:43, Ryota Ozaki wrote: BTW I committed a change that disables IFEF_MPSAFE by default on all interfaces because it seems that IFEF_MPSAFE requires additional

Re: struct ifnet locking [was Re: IFEF_MPSAFE]

Hi, does this panic (with -current/amd64 as of 20171221) ring a bell with anyone? shortly after starting mrouted and ntpd: panic: kernel diagnostic assertion "IFNET_LOCKED(ifp)" failed: file "/src/NetBSD/cur/src/sys/net/if.c", line 3602 fatal breakpoint trap in supervi

Re: Removing an entry from struct emul

On 21.12.2017 10:43, Martin Husemann wrote: > On Thu, Dec 21, 2017 at 07:16:09AM +, co...@sdf.org wrote: >> Hi, >> >> COMPAT_IRIX needed e_fault, an alternative implementation of uvm_fault. >> But it's been removed. can I remove e_fault from the struct, or would >> this break compat too hard?

Re: Removing an entry from struct emul

On Thu, Dec 21, 2017 at 07:16:09AM +, co...@sdf.org wrote: > Hi, > > COMPAT_IRIX needed e_fault, an alternative implementation of uvm_fault. > But it's been removed. can I remove e_fault from the struct, or would > this break compat too hard? > > Its sole use is a check in mips/trap.c. I

Re: workqueue_drain

On Wed, Dec 20, 2017 at 5:41 PM, Ryota Ozaki wrote: > On Wed, Dec 20, 2017 at 4:57 PM, Paul Goyette wrote: >> On Wed, 20 Dec 2017, Ryota Ozaki wrote: >> >>> Hi, >>> >>> workqueue_destroy requires that its queue doesn't have >>> any works (and no new work

Re: workqueue_drain

On Thu, Dec 21, 2017 at 5:58 AM, Michael van Elst wrote: > ozak...@netbsd.org (Ryota Ozaki) writes: > >>On Wed, Dec 20, 2017 at 8:06 PM, Michael van Elst wrote: >>> What about a method that waits for a specific work to complete? > >>It might be useful but