Re: Straw proposal: MI kthread vector/fp unit API

Erik Fair wrote: > > I think it’d be better to call this a co-processor API (or something else > along these lines less specific than “FPU”), and type the co-processor > and its required, additional context for generality - just to look ahead > a little bit. > FYI:

Re: Reproducible NetBSD 9.0/amd64 panic, but no crash dump

Hi, John Klos wrote: > [ 236045.981322] thmap_del() at netbsd:thmap_del+0x218 > ... Can you please a) run objdump -D /netbsd and send me the assembly of the above function? b) provide your kernel image (off-list)? Thanks. -- Mindaugas

Re: Changes to reduce pressure on uvm_pageqlock

Chuck Silvers wrote: > In your new diff, the pageq lock is still used by the pagedaemon > (for uvmpd_trylockowner() as you noted in the comment). > It would be good not to have a global lock involved in changing page > identity, and with the pageq's now protected by a separate lock, we > should

Re: racy acccess in kern_runq.c

Maxime Villard wrote: > Le 06/12/2019 à 17:53, Andrew Doran a écrit : > > On Fri, Dec 06, 2019 at 05:22:39PM +0900, Kengo NAKAHARA wrote: > > > >>/* Update the worker */ > >> - worker_ci = hci; > >> + atomic_swap_ptr(_ci, hci); > > > > Why atomic_swap_ptr() not atomic_store_relaxed()? I

Re: __{read,write}_once

David Holland wrote: > > I see the potential source of confusion, but just think about: what > > could "atomic" possibly mean for loads or stores? A load is just a > > load, there is no RMW cycle, conceptually; inter-locking the operation > > does not make sense. For anybody who attempts to

Re: __{read,write}_once

Maxime Villard wrote: > > > > I suggest __atomic_load_relaxed()/__atomic_store_relaxed(). > > What I don't like with "atomic" in the name is that the instructions > generated are not atomic strictly speaking, and I'd rather avoid the > confusion with the really atomic instructions. I see the

Re: __{read,write}_once

Maxime Villard wrote: > Alright so let's add the macros with volatile (my initial patch). Which > name do we use? I actually like __{read,write}_racy(). I suggest __atomic_load_relaxed()/__atomic_store_relaxed(). If these are to be provided as macros, then I also suggest to ensure that they

Re: __{read,write}_once

Maxime Villard wrote: > > Alright, thanks. > > Do you think there is a performance degradation with using explicitly > atomic operations (with the "lock" prefix on x86), compared to just using > an aligned volatile which may not be exactly atomic in that sense (even > if it happens to be on

Re: __{read,write}_once

Maxime Villard wrote: > > They are "atomic" in a sense that they prevent from tearing, fusing and > > invented loads/stores. Terms and conditions apply (e.g. they assume > > properly aligned and word-sized accesses). Additionally, READ_ONCE() > > provides a data-dependency barrier, applicable

Re: __{read,write}_once

Maxime Villard wrote: > > - If we do not want to stick with the C11 API (its emulation), then I > > would suggest to use the similar terminology, e.g. atomic_load_relaxed() > > and atomic_store_relaxed(), or Linux READ_ONCE()/WRITE_ONCE(). There is > > no reason invent new terminology; it might

Re: __{read,write}_once

Maxime Villard wrote: > There are cases in the kernel where we read/write global memory > locklessly, and accept the races either because it is part of the design > (eg low-level scheduling) or we simply don't care (eg global stats). > > In these cases, we want to access the memory only once,

C11 memory fences, atomics, memory model

Hi, There have been some discussions amongst the developers about the C11 memory model. It seemed that there was a lot of confusion and a general lack of clarity in this subject. I wrote a quick summary describing some of the key points of the C11 memory model and key aspects of the memory

Re: Removing PF

"John D. Baker" wrote: > > > > ifaddrs(netifN) represents a list of addresses currently assigned the > > interface i.e. it works dynamically, you do not need to `npfctl reload`. > > So, to be clear, if an interfaces gains/sheds addresses, ifaddrs(netifN) > will always reflect the current set of

Re: Removing PF

"John D. Baker" wrote: > Is it possible to assign multiple addresses in a dynamic fashion > (DHCP, PPP[oE], ???) that ifaddrs(netifN) is meaningful? ifaddrs(netifN) represents a list of addresses currently assigned the interface i.e. it works dynamically, you do not need to `npfctl reload`. In

Re: Removing PF

"John D. Baker" wrote: > > > - dynamic ifaddrs(netifN) (John D. Baker) > > The "ifaddrs(netifN)" function is what evaluates the addresses on the > interface with each reference in a rule, or so the documentation makes > it appear. Contrast with "inet4(netifN)" or "inet6(netifN)" that is > only

Re: Removing PF

Taylor R Campbell wrote: > > - mss clamping (Brian Buhrow) This is supported and has been documented for years.. > - ftp-proxy (Jan Danielsson) > ... > - dynamic NAT updates These two are related and should soon be addressed. > - pf route-through/reply-to (Brian Buhrow) That is more of

Re: Removing PF

Jan Danielsson wrote: > On 2019-04-02 08:53, Martin Husemann wrote: > >> This, exactly, is the showstopper that has prevented me from moving to > >> npf. The ability to add/remove IP addresses from a NAT translation > >> without changing npf.conf doesn't seem to be possible in any > >>

Re: Removing PF

mlel...@serpens.de (Michael van Elst) wrote: > > >Just to get the facts straight: NPF has a bigger market share *outside* > >NetBSD, at least certainly for commercial users. They also contribute. > > Ironically, the same is also true for PF... > Well that tells something about NetBSD, doesn't

Re: Removing PF

Brian Buhrow wrote: > <...> what would make it harder to maintain than NPF, which has > absolutely no market share outside of NetBSD? Just to get the facts straight: NPF has a bigger market share *outside* NetBSD, at least certainly for commercial users. They also contribute. -- Mindaugas

Re: Ubiquitous ucas(9)

Jason Thorpe wrote: > Folks... > > I'm trying to wrap up my ufetch / ustore changes > (http://mail-index.netbsd.org/tech-kern/2019/02/23/msg024690.html), and I > realized there's another requirement that the project I'm working on > has... specifically, ucas_int() ... for those unfamiliar, this

Re: RFC: New userspace fetch/store API

Jason Thorpe wrote: > > Please prefix the size with 'u' if you operate on unsigned types: > > > > ufetch_u{8,16,32,64} and the same for ustore_* > > Even at the expense of being different from atomic_ops(3)? > atomic_ops(3) has atomic_cas_u{int,long}; ufetch_32() vs ufetch_u32() is less of

Re: RFC: New userspace fetch/store API

Jason Thorpe wrote: > The existing fetch(9) / store(9) APIs have some problems. Specifically: > > ==> Their return semantics mean that fuword() cannot disambiguate between > an error condition (-1) and a legitimate fetch of -1 from user space. > > ==> “word” is poorly defined. For all

Re: Support for "pshared" POSIX semaphores

Jason Thorpe wrote: > Patch is here: > https://patch-diff.githubusercontent.com/raw/thorpej/netbsd-src/pull/5.diff Thanks for working on this. - Why not just add a new syscall, instead of the KSEM_PSHARED stuff? - If you add the 'fd' parameter to ksem_release(), then you can move

Re: Concurrent trie-hash map

Jason Thorpe wrote: > > I think this is a great thing to add to kern/ as a general facility. > There are applications beyond just the network stack, as well -- any > read-mostly hash table that has a lock or an array-of-locks around it is > a good candidate for being replaced by this. > In

Concurrent trie-hash map

Hi, I recently implemented thmap [1] -- a concurrent trie-hash map, combining the elements of hashing and radix trie. It is supports lock-free lookups and concurrent inserts/deletes. It is designed to be optimal as a general purpose *concurrent* associative array [2][3]. I am going to import

Re: libnv

Kamil Rytarowski wrote: > On 27.08.2018 02:39, Mindaugas Rasiukevicius wrote: > > Hi, > > > > Here is patch to import the FreeBSD's libnv library: > > > > http://www.netbsd.org/~rmind/libnv.diff > > > > For more details on libnv: > >

Re: libnv

Joerg Sonnenberger wrote: > > > > Here is patch to import the FreeBSD's libnv library: > > > > http://www.netbsd.org/~rmind/libnv.diff > > I don't think anything has changed since the last time this was > discussed, so I consider this a really, really wrong idea going forward. > The only

libnv

Hi, Here is patch to import the FreeBSD's libnv library: http://www.netbsd.org/~rmind/libnv.diff For more details on libnv: https://www.freebsd.org/cgi/man.cgi?query=nv=9 I have already converted the standalone/upstream NPF to use libnv, so it would be the first user of this library. Thanks.

Re: 8.0 performance issue when running build.sh?

Jason Thorpe wrote: > > > > On Aug 9, 2018, at 10:40 AM, Thor Lancelot Simon wrote: > > > > Actually, I wonder if we could kill off the time spent by fileassoc. Is > > it still used only by veriexec? We can easily option that out of the > > build box kernels. > > Indeed. And there are

Re: repeated panics in mutex_vector_enter (from unp_thread)

Edgar Fuß wrote: > Since a few days, I'm experiencing repeated panics in mutex_vector_enter. > > <...> > > db{5}> bt > mutex_vector_enter() at netbsd:mutex_vector_enter+0x32c > unp_thread() at netbsd:unp_thread+0x2eb - Can you reproduce the problem with the LOCKDEBUG, DEBUG and DIAGNOSTIC

Re: 8.0 performance issue when running build.sh?

Martin Husemann wrote: > So here is a more detailed analyzis using flamegraphs: > > https://netbsd.org/~martin/bc-perf/ > > > All operations happen on tmpfs, and the locking there is a significant > part of the game - however, lots of mostly idle time is wasted and it is > not clear to

Re: workqueues ....

Phil Nelson wrote: > On Thursday 26 July 2018 23:23:13 Taylor R Campbell wrote: > > static void > > foo_intr(...) > > { > > ... > > mutex_enter(>sc_work_lock); > > if (!sc->sc_work_scheduled) { > > workqueue_enqueue(sc->sc_wq, >sc_work, NULL); > >   

Re: workqueues ....

Phil Nelson wrote: > I'm getting a mutex error here in that the lock is held. > Backtrace: > System panicked: LOCKDEBUG: Mutex error: mutex_vector_enter,528: spin > lock held Backtrace from time of crash is available. > crash> bt > _KERNEL_OPT_NARCNET() at 0 > _KERNEL_OPT_ACPI_SCANPCI() at

Re: performance issues during build.sh -j 40 kernel

Mateusz Guzik wrote: > ... > > 1) #define UBC_NWINS 1024 > > The parameter was set in 2001 and is used on amd64 to this very day. > > lockstat says: > 51.63 585505 321201.06 e4011d8304c0 > 40.39 291550 251302.17 e4011d8304c0 ubc_alloc+69 > 9.13

Re: x86: per-cpu tmp vas

Maxime Villard wrote: > ... > > This patch fixes the two aforementioned issues: the VAs are allocated > proportionally to the number of CPUs attached so we don't uselessly lose > memory, and there is no false sharing since the cpu_info structures are > already

Re: Enormous scheduler bug

Maxime Villard m...@m00nbsd.net wrote: Index: sys_pset.c === RCS file: /cvsroot/src/sys/kern/sys_pset.c,v retrieving revision 1.18 diff -u -r1.18 sys_pset.c --- sys_pset.c25 Feb 2014 18:30:11 - 1.18 +++

Re: RFC: IRQ affinity (aka interrupt routing)

Hi, Kengo NAKAHARA k-nakah...@iij.ad.jp wrote: There has been no objection for about 10 months... So, I am going to commit this implementation. Here is the rebased patch, http://netbsd.org/~knakahara/intrctl/intrctl.patch If there is no objection, I commit this patch after a few days.

Re: Threaded file system benchmark

Ryo ONODERA ryo...@yk.rim.or.jp wrote: ... --- a/gettime.c +++ b/gettime.c @@ -483,18 +483,30 @@ static void *clock_thread_fn(void *data) { struct clock_thread *t = data; struct clock_entry *c; +#if defined(__NetBSD__) + os_cpu_mask_t *cpu_mask = cpuset_create();

Re: pserialize hw interrupt

Ryota Ozaki ozak...@netbsd.org wrote: Can we use pserialize for readers in hardware interrupt? If we use splhigh instead of splsoftserial (pserialize_read_enter) for critical sections of the readers, we can guarantee that the readers don't touch a removed object anymore after

Re: Invalidate page cache

m...@netbsd.org (Emmanuel Dreyfus) wrote: Is there a way to invalidate the page cache of a given file, from userland? I understand fsync() will flush pending writes, but what about if we want to flush cached data? Currently, there is no mechanism to flush the page cache. If the underlying

Re: Critical section

Masao Uebayashi uebay...@gmail.com wrote: On Fri, Nov 28, 2014 at 8:47 AM, Mindaugas Rasiukevicius rm...@netbsd.org wrote: Masao Uebayashi uebay...@gmail.com wrote: The problem of kpreempt_*() API is that its meaning is overriden by kernel internal (scheduler, sync primitives

Re: pserialized queue(9)

Dennis Ferguson dennis.c.fergu...@gmail.com wrote: On 28 Nov, 2014, at 07:33 , Mindaugas Rasiukevicius rm...@netbsd.org wrote: Dennis Ferguson dennis.c.fergu...@gmail.com wrote: Yes, Joerg broke the name cache concurrency. This has to be fixed or at least reverted for netbsd-7. He

Re: pserialized queue(9)

Dennis Ferguson dennis.c.fergu...@gmail.com wrote: On 25 Nov, 2014, at 08:29 , Mindaugas Rasiukevicius rm...@netbsd.org wrote: Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: The attached patch adds _PSZ variants to all the insert, remove, and foreach operations in sys

Re: Critical section

Masao Uebayashi uebay...@gmail.com wrote: The problem of kpreempt_*() API is that its meaning is overriden by kernel internal (scheduler, sync primitives, ...). This change separates the internal use (scheduler disables preeemption) and others (kernel subsystem code executes critical

Re: Critical section

Masao Uebayashi uebay...@gmail.com wrote: On Thu, Nov 27, 2014 at 1:38 AM, Matt Thomas m...@3am-software.com wrote: That is not true. If the softint thread sleeps, control is returned back to the preempted lwp. You're right. I keep forgetting how softint works. Sigh. ... (Calling

Re: pserialized queue(9)

Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: The attached patch adds _PSZ variants to all the insert, remove, and foreach operations in sys/queue.h to issue the necessary store barriers, for insert, and data-dependent load barriers, for foreach. ... Please do not. In

Re: pserialize(9) vs. TAILQ

Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: Date: Fri, 21 Nov 2014 18:25:02 +0800 From: Dennis Ferguson dennis.c.fergu...@gmail.com Beyond the Alpha-barrier, he only thing I find lacking about the membar_*() API is maybe a set of functions that would eliminate the

Re: Proposal: kmem_valloc [was: Re: raspberry pi panic 7.0_BETA after install fs resize]

Maxime Villard m...@m00nbsd.net wrote: Hi, there's something terribly sad with the kmem API: kmem_free takes a size argument. It has I think two major drawbacks: ... Here is a patch which implements kmem_valloc. Comments? I object to such addition; others already explained various

Re: FFS: wrong superblock check ~ crash

Manuel Bouyer bou...@antioche.eu.org wrote: On Mon, Oct 20, 2014 at 03:58:45PM +, Taylor R Campbell wrote: Date: Mon, 20 Oct 2014 17:46:06 +0200 From: Manuel Bouyer bou...@antioche.eu.org Sure. There's lot of other ways to crash the kernel with a broken ffs. In this

Re: FFS: wrong superblock check ~ crash

Manuel Bouyer bou...@antioche.eu.org wrote: On Mon, Oct 20, 2014 at 07:48:31PM +0100, Mindaugas Rasiukevicius wrote: definitively not. I want a panic. If the filesystsem is corrupted something has gone really wrong and you can't trust the running system any more. And there are cases

Re: FFS: wrong superblock check ~ crash

mlel...@serpens.de (Michael van Elst) wrote: rm...@netbsd.org (Mindaugas Rasiukevicius) writes: If I have a system with an array of disks and one of them fails, a crash would take down the whole node. When many terabytes of data suddenly disappear people get unhappy; When a single node

Re: Unreleased vnode in linux_sys_uselib()

Maxime Villard m...@m00nbsd.net wrote: Hi, there seems to be a vnode issue in compat/linux/common/linux_uselib.c: ... And I'm wondering: what is the impact of such bugs? njoly@ tested a small sample I sent him and apparently there doesn't seem to be any glaring issue. It is a resource

Re: build kernel from source

Alan Barrett a...@cequrux.com wrote: On Mon, 22 Sep 2014, bycn82 wrote: *Now I am building the npfctl, and I met below** * -Wsign-compare -Wformat=2 -Werror -I/usr/src/usr.sbin/npf/npfctl --sysroot=/ -c /usr/src/usr.sbin/npf/npfctl/npf_bpf_comp.c In file included from

Re: RFC: IRQ affinity (aka interrupt routing)

Matt Thomas m...@3am-software.com wrote: As I've been reading this discussion, it seems very x86 centric. I've thinking about adding void intr_distribute(void *ih, const kcpuset_t *newset, kcpuset_t *oldset) Agree. And this would be MI interface. Just as Kengo-san already pointed

Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

Ryota Ozaki ozak...@netbsd.org wrote: I generally agree with Dennis that is not the way we want to take in the long-term. The cost of read-write lock is very high. The plan is to use passive serialisation to protect the interfaces and their addresses. Also, the ultimate goal would also

Re: Making bpf MPSAFE (was Re: struct ifnet and ifaddr handling ...)

Ryota Ozaki ozak...@netbsd.org wrote: Hi, I thought I need more experience of pserialize (and lock primitives) to tackle ifnet work. So I suspended the work and now I am trying another easier task, bpf. http://www.netbsd.org/~ozaki-r/mpsafe-bpf.diff As Darren mentioned - there are

Re: Making bpf MPSAFE (was Re: struct ifnet and ifaddr handling ...)

Darren Reed darr...@netbsd.org wrote: Looking at the use of pserialze functions, you've got a single data structure (bpf_iflist) that is at some times covered by bpf_iflist_mtx and others not. That's a bad design. Ideally the data structure should only be covered by one locking mechanism so

Re: RFC: IRQ affinity (aka interrupt routing)

Kengo NAKAHARA k-nakah...@iij.ad.jp wrote: Sorry, I typo the patch URL. (2014/08/20 18:06), Kengo NAKAHARA wrote: and here is the patch http://knakahara.github.io/patches/netbsd/irq-affinity-initctl.patch http://knakahara.github.io/patches/netbsd/irq-affinity-intrctl.patch

struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

Ryota Ozaki ozak...@netbsd.org wrote: Hi, This is another work toward MPSAFE networking. sys/net/if.c contains several global variables (e.g., ifnet_list) that should be protected from parallel accesses somehow once we get rid of the big kernel lock. Currently there is a mutex for

Re: pserialized reader/writer locks

Taylor R Campbell riastr...@netbsd.org wrote: While reading the fstrans(9) code a few months ago and trying to understand what it does, I threw together a couple of simple pserialize(9)-based reader/writer locks -- one recursive for nestable transactions like fstrans(9), the other

Re: task queues

Taylor R Campbell riastr...@netbsd.org wrote: We don't have a nice easy lightweight way for a driver to ask that a task be executed asynchronously in thread context. The closest we have is workqueue(9), but each user has to do bookkeeping for a different workqueue and incurs a long-term

Re: RFC: IRQ affinity (aka interrupt routing)

Kengo NAKAHARA k-nakah...@iij.ad.jp wrote: The implementation is consist of following three pathes: ... (2) new kernfs file to show interrupt numbers per cpu vmstat -i cannot show interrupt numbers per cpu. So I implement new kernfs file to show per cpu. The usage is cat

Re: pserialized reader/writer locks

Taylor R Campbell riastr...@netbsd.org wrote: Date: Sat, 26 Jul 2014 16:48:27 +0100 From: Mindaugas Rasiukevicius rm...@netbsd.org I would expect a better problem statement even if it is a brain dump (one sentence would have been enough). Are you trying to solve sleepable reader

Re: CVS commit: src/sys/kern

chris...@astron.com (Christos Zoulas) wrote: In article 53d288c7.5000...@m00nbsd.net, Maxime Villard m...@m00nbsd.net wrote: Well, if only these architectures are running with DIAGNOSTIC, that's not a big deal. Anyway, let's put KMEM_DIAGNOSTIC. I like KMEM_DIAGNOSTIC, can you add it, or

Re: Bridge forwarding employing pktqueue

Ryota Ozaki ozak...@iij.ad.jp wrote: An integrated patch is attached and available here: http://www.netbsd.org/~ozaki-r/bridge-pktq.diff Why xc_broadcast()? I just followed the code of if_detach though, we need to wait for pktq_barrier (packet draining) completion here. Otherwise, the

Re: Bridge forwarding employing pktqueue

Ryota Ozaki ozak...@iij.ad.jp wrote: The summary of the changes: - Add pktqueue_t *sc_fwd_pktq to bridge_softc - Add net.interfaces.bridgeN.fwdq.{maxlen,len,drops} sysctl - Add 3rd argument to pktq_create to pass sc to softint_establish - Export sysctl_pktq_maxlen and sysctl_pktq_count

Re: Lockless IP input queue, the pktqueue interface

Ryota Ozaki ozak...@netbsd.org wrote: Hi rmind, maxlen of ip{,6}_pktq cannot be updated via sysctl. It seems that we need to do it in sysctl_pktq_count somehow. Now it can: http://mail-index.netbsd.org/source-changes/2014/06/09/msg055432.html -- Mindaugas

Re: Big test regression in -current

Martin Husemann mar...@duskware.de wrote: Something seriously happened to -current in the last few days. Between June 2 and June 8 the number of test failures jumped from 17 to 80, see: http://www.netbsd.org/~martin/sparc64-atf/ Some rump test crash like this: panic: kernel diagnostic

Re: Making tmpfs reserved memory configurable

Martin Husemann mar...@duskware.de wrote: ... See mount_tmpfs(8), in the paragraph about the -s option: Note that four megabytes are always reserved for the system and cannot be assigned to the file system. This wording may be confusing. tmpfs does not reserve the memory in a

Re: Lockless IP input queue, the pktqueue interface

Darren Reed darr...@netbsd.org wrote: On 29/05/2014 5:06 AM, Mindaugas Rasiukevicius wrote: Darren Reed darr...@netbsd.org wrote: No, there is no need to expose the structure. Even if there would be another internal component using the structure(s) one should consider accessors/mutators

Lockless IP input queue, the pktqueue interface

Hello, As we are trying to bring more parallelism in our network stack, I would like to make IPv4 and IPv6 input queues lockless. This is implemented by replacing struct ifqueue and macros around it with a pktqueue interface. This interface also abstracts and handles network ISR scheduling and

Re: cprng_fast implementation benchmarks

paul_kon...@dell.com wrote: No. There is a strong RNG, based on the NIST SP800-90 CTR_DRBG with AES128 as the block transform. There is also a fast RNG, based on RC4. We are discussing the replacement of the fast RNG. Ok. But if that’s a non-strong RNG, why are we discussing

Re: cprng_fast implementation benchmarks

paul_kon...@dell.com wrote: There are cases when both security and performance matters. Consider TCP ISN generation or UDP port number generation (i.e. randomisation). There are known security issues if these numbers can be predicted, but at the same time, high performance penalty is

Re: Towards design criteria for cprng_fast()

Thor Lancelot Simon t...@panix.com wrote: I would like to offer some observations about the use of cprng_fast() (once known as arc4random()) in our kernel and, from these, express what I believe are reasonable design criteria for that function. O1) cprng_fast() is used in some

Re: Patch: cprng_fast performance - please review.

Thor Lancelot Simon t...@panix.com wrote: On Wed, Apr 16, 2014 at 09:52:22PM -0400, Thor Lancelot Simon wrote: Attached is a patch which makes cprng_fast per-CPU and lockless. *IT IS NOT WELL TESTED YET (I haven't even run test vectors) AND IS ONLY FOR REVIEW.* New diff, with some

Re: cprng_fast implementation benchmarks

Thor Lancelot Simon t...@panix.com wrote: RESULTS kernelcpb (32 bit)4GB (1 way) 16GB (4 ways) Scaling Factor ----- - -- arc4-mtx 35 42.58 398.83 0.106 arc4-nomtx24

Re: cprng_fast implementation benchmarks

Manuel Bouyer bou...@antioche.eu.org wrote: On Wed, Apr 23, 2014 at 09:16:33AM -0400, Thor Lancelot Simon wrote: [...] Do we still have a compile-time way to check if the kernel (or port) is uniprocessor only? If so we should probably #ifdef away the percpu calls in such kernels, which

Re: Changes to make /dev/*random better sooner

Thor Lancelot Simon t...@panix.com wrote: On Wed, Apr 09, 2014 at 02:43:23AM +0100, Mindaugas Rasiukevicius wrote: This is a very positive work for the cases when system is used as a server or other workloads which may involve cryptographic activity. However, you seem to assume

Re: Changes to make /dev/*random better sooner

Thor Lancelot Simon t...@panix.com wrote: Attached are the changes from the tls-earlyentropy branch, which tries to make the output of /dev/random less predictable -- particularly for an attacker outside the box -- earlier. This is a very positive work for the cases when system is used as a

Re: Vnode API change: add global vnode cache

J. Hannken-Illjes hann...@eis.cs.tu-bs.de wrote: Currently all file systems have to implement their own cache of vnode / fs node pairs. Most file systems use a copy and pasted version of ufs_ihash. So add a global vnode cache with lookup and remove: ... Diff implementing this for file

Re: Vnode API change: add global vnode cache

Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: Date: Mon, 7 Apr 2014 16:44:47 +0100 From: Mindaugas Rasiukevicius rm...@netbsd.org One concern though: can you benchmark ./build.sh on a machine with 8 or more CPUs? I fear that vcache.lock might be a bit contended

Re: Vnode API change: add global vnode cache

Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: Date: Mon, 7 Apr 2014 17:27:01 +0100 From: Mindaugas Rasiukevicius rm...@netbsd.org Should be fine, but once tmpfs is switched to use vcache, it might become a little bit more visible for some workloads.. Why switch

Re: Vnode API change: add global vnode cache

Alan Barrett a...@cequrux.com wrote: On Mon, 07 Apr 2014, Mindaugas Rasiukevicius wrote: Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: What is intern? `Intern' means `lookup, or create and insert if not there'. The point being is that I do not find it meaningful

AsiaBSDCon 2014 P2B: NPF - progress and perspective

Hello, Here are the slides of the NPF - progress and perspective presentation: http://www.netbsd.org/~rmind/pub/npf_asiabsdcon_2014.pdf You can also find the paper in the AsiaBSDCon 2014 Proceedings. Thank you. -- Mindaugas

Re: ci_mtx_count issue on NetBSD/Milkymist

Yann Sionneau yann.sionn...@gmail.com wrote: It asserts for -1 because only the LWP lock should be held at that point. Ok, but locking the LWP lock won't make ci_mtx_count be -1 because the lock is a MUTEX_DEFAULT and not a MUTEX_SPIN. MUTEX_DEFAULT can either mean a spin-lock or an

Re: ci_mtx_count issue on NetBSD/Milkymist

Yann Sionneau yann.sionn...@gmail.com wrote: I've tried to understand how ci_mtx_count is supposed to be managed my MD code, so far I failed to understand. It seems some arch use spin_mutex and inc/dec ci_mtx_count upon spin_mutex_enter/exit. Some other archs do it in softint handling.

Re: pmap_kenter_pa pmap_kremove

Matt Thomas m...@3am-software.com wrote: I've been wondering... Should pmap_kenter_pa overwrite an existing entry should it be operating on an unmapped VA. You mean already mapped VA? I think that if you want to change a mapping, you should do a pmap_kremove first. I tend to agree. I

The lamentation of proplib(3)

Hello, Many developers have been dissatisfied with proplib(3) for quite a while and my own dissatisfaction has reached the point where I decided to raise the question. The question of replacing proplib(3) with a better library. There were ideas by some developers to write a new library from

Re: The lamentation of proplib(3)

Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: I don't think there's much disagreement that proplib is wrong, but a proposal to replace it ought to include concrete examples of how current uses of proplib (or C structs or other wire data transmission formats) should be replaced,

Re: The lamentation of proplib(3)

Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote: If you have taken a look at the manual page and the examples section, the API is straightforward. I do not think that we all need to hold our hands and learn together that prop_dictionary_create() would be replaced with

Re: BPF memstore and bpf_validate_ext()

Alexander Nasonov al...@yandex.ru wrote: Mindaugas Rasiukevicius wrote: Moreover, the usual byte-code produced by tcpdump/pcap does not even use the memory store so you optimisations would most of the time be applicable anyway! This is not always the case. For instance, # tcpdump -y

Re: BPF memstore and bpf_validate_ext()

Alexander Nasonov al...@yandex.ru wrote: The external memory store can be used as an argument (and the initial values determined as proposed in this thread). If you want, we can pass it as a third argument, I just think it is a pointless indirection level. Would even need extra wrapping

Re: BPF memstore and bpf_validate_ext()

Alexander Nasonov al...@yandex.ru wrote: Well, if it wasn't needed for many year in bpf, why do we need it now? ;-) Because it was decided to use BPF byte-code for more applications and that meant there is a need for improvements. It is called evolution. :) To answer your question about a

Re: BPF memstore and bpf_validate_ext()

Alexander Nasonov al...@yandex.ru wrote: Mindaugas Rasiukevicius wrote: Also, it was you who proposed sljit. Proposed for what? I implemented bpfjit using sljit if that's what you mean. I offered you a help with implementing jit compiler for npfcode. It was your idea to add COP/COPX and I

Re: BPF memstore and bpf_validate_ext()

Darren Reed darr...@netbsd.org wrote: On 16/12/2013 3:20 AM, Alexander Nasonov wrote: .. This discussion is going to nowhere. At this point, someone from outside should review our opinions and help us to make a decision. It is one hack after another to support NPF using tables in BPF.

Re: BPF memstore and bpf_validate_ext()

Alexander Nasonov al...@yandex.ru wrote: All your recent changes to adapt bpfjit for npf show that you're hitting sljit limitation all the time. Your expectations of sljit are probably too high. We are discussing the external memory store which is useful regardless whether BPF program is

Re: UVM crash in NetBSD/i386 PAE with 32 GB of RAM

Martin Husemann mar...@duskware.de wrote: On Fri, Dec 13, 2013 at 01:16:08PM +, Emmanuel Dreyfus wrote: panic: lock error Can you try this with a LOCKDEBUG kernel? Martin Will not help. This is a trap in x86 pmap, the locking error is just a side effect, not an issue in UVM. Quite

Re: BPF memstore and bpf_validate_ext()

Alexander Nasonov al...@yandex.ru wrote: If this is the case, you don't need BPF_COP at all. For this particular case - yes, correct. Except of course you may run out or memwords one day and you want to have BPF_COP as a fallback. I still need BPF_COP for other tasks

BPF memstore and bpf_validate_ext()

Hello, Now that the BPF memory store can be external and can be provided by the caller of the BPF program, we can use to it pass some values or reuse it as a cache. However, this has to be supported by bpf_validate() - we have to tell it which words are going to be initialised by the caller,

Re: suprious reboot on netbsd-6:i386 with PAE

Emmanuel Dreyfus m...@netbsd.org wrote: Hi I am still trying to work aroud the spurious reboots I get on netbsd-6/i386 with PAE. It happens on different machines when the load rises, and -current/i386 is not affected. Can you try a kernel with DEBUG, DIAGNOSTIC and LOCKDEBUG (this one is

  1   2   3   >