Re: uvm_object::vmobjlock

2010-01-28 Thread Mindaugas Rasiukevicius
Antti Kantee po...@cs.hut.fi wrote: ... Given the gruesome size of the rototill, I think you'll agree it's important for everyone to have a clear idea about the implications beforehand beyond it'll be better. Agree, hence this thread. If you are talking about memory not within the object,

Re: unhooking lfs from ufs

2010-02-07 Thread Mindaugas Rasiukevicius
David Holland dholland-t...@netbsd.org wrote: The copy involves 18 files from sys/ufs/ufs (out of 21; the ones excluded are quota.h and unsurprisingly ufs_wapbl.[ch]) which contain 9067 lines of code. That gives the following statistics: 14988size of lfs currently + 9067

Re: unhooking lfs from ufs

2010-02-07 Thread Mindaugas Rasiukevicius
David Holland dholland-curr...@netbsd.org wrote: How would this affect UFS side? For example, any potential code reduction and/or simplification? Yes. ufs_readwrite.c will become much less gross, for example. There used to be assorted LFS-only code in the ufs sources; ad@ removed the

Dead ports [Re: config(5) break down]

2010-03-19 Thread Mindaugas Rasiukevicius
Andrew Doran a...@netbsd.org wrote: I *do* think it's a useful datapoint to note that sun2, pmax, algor, etc. are never, ever downloaded any more. Right, and these dead ports must be euthanized. The mountain of unused device drivers and core kernel code is a signficant hinderance to

Re: Dead ports [Re: config(5) break down]

2010-03-19 Thread Mindaugas Rasiukevicius
der Mouse mo...@rodents-montreal.org wrote: [...] sun2, pmax, algor, etc. [...] Right, and these dead ports must be euthanized. For those single developers who still have such machines, as a hardware replacement and moral compensation, TNF could buy some new ARM or MIPS board for

Re: getiobuf(x, false) can sleep ?

2010-04-04 Thread Mindaugas Rasiukevicius
Manuel Bouyer bou...@antioche.eu.org wrote: The mutex_enter() in the pool_cache_get_slow()? This cache won't sleep if PR_NOWAIT, it's interrupt safe. ... I've been running with the attached patch for a day now (the workaround for bp changing under us was already there for a

Re: getiobuf(x, false) can sleep ?

2010-04-08 Thread Mindaugas Rasiukevicius
Andrew Doran a...@netbsd.org wrote: This is concerning. As mentioned, bufio_cache is interrupt safe (marked with IPL_BIO) and locks at pool_cache(9) layer, also deeper layers e.g. UVM kva-cache, should use spin-locks at IPL_VM. There is one possibly related mysterious backtrace -

Re: KASSERT() in kern_timeout.c

2010-04-19 Thread Mindaugas Rasiukevicius
Manuel Bouyer bou...@antioche.eu.org wrote: On Mon, Apr 19, 2010 at 04:10:15PM +0100, Mindaugas Rasiukevicius wrote: To answer your previous question - yes, that is what I meant, plus other amendments you have already made. Note: it might also be useful to manually trigger callout

Re: updating COMPAT_LINUX for linux 2.6.x support.

2010-05-02 Thread Mindaugas Rasiukevicius
Hello, Chuck Silvers c...@chuq.com wrote: hi folks, I've started looking at what it would take to update COMPAT_LINUX to allow changing the emulated linux kernel version to 2.6.x. Great! (2) what linux kernel version do we want to claim to be in uname? it would be good for this to be

Re: Red-black tree optimisation

2010-05-04 Thread Mindaugas Rasiukevicius
Hello, Adam Ciarciński a...@netbsd.org wrote: Because at one point I studied red-black trees (not as in dendrology, but as data structures), I looked into the implementation that is being used in NetBSD. I have made some drastic optimisations on sys/ sys/tree.h and would like to have the

Re: allocating memory during kernel startup

2010-05-07 Thread Mindaugas Rasiukevicius
Michael macal...@netbsd.org wrote: Any chance to just have kmem_alloc() immediately return NULL if it isn't ready yet so we can fail gracefully instead of hanging? Such handling, i.e. in kmem(9), seems like a wrong approach to me. Caller can check the 'cold' variable, which is unset in

Re: allocating memory during kernel startup

2010-05-07 Thread Mindaugas Rasiukevicius
Martin Husemann mar...@duskware.de wrote: Well, kmem(9) is initialised very early, just after pool(9), in uvm_init (), where I moved it couple years ago. Yes, 'cold' is unset very late. Since allocation gets postponed anyway, is that a problem? You did not describe your use case. :)

Re: __read_mostly and __mp_friendly annotations

2010-05-25 Thread Mindaugas Rasiukevicius
Matt Fleming m...@console-pimps.org wrote: On Sun, 23 May 2010 12:20:15 +0200, Martin Husemann mar...@duskware.de wrote: Looks good, but the __mp_friendly name is not quite obvious. Why not call it __cacheline_aligned? I could have sworn that I called it that originally, but maybe not. I

Re: updating COMPAT_LINUX for linux 2.6.x support (take 2)

2010-06-04 Thread Mindaugas Rasiukevicius
Hello, Chuck Silvers c...@chuq.com wrote: I rewrote my COMPAT_LINUX changes using the 1-proc-many-LWPs model. the patch is at: ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/linux/diff.linux-nptl-take2.23 I like this patch a lot! Especially good clean-ups, as a result. Few comments: -

Re: updating COMPAT_LINUX for linux 2.6.x support (take 2)

2010-06-16 Thread Mindaugas Rasiukevicius
Andrew Doran a...@netbsd.org wrote: - The dup code for fork1() code makes me uncomfortable. Maybe it's worthwhile changing our native code so that LIDs are always allocated from the PID table or something along those lines? Tend to think these should be globally unique with the system

Re: 5.99.30 sparc panic during startup

2010-06-19 Thread Mindaugas Rasiukevicius
David Young dyo...@pobox.com wrote: ... config_alldevs_lock(0x0, 0x700, 0x0, 0x0, 0x0, 0xf416c660) at netbsd:device_lookup+0x4 device_lookup(0xf0335ebc, 0x0, 0x37f, 0xf0307208, 0x0, 0x0) at netbsd:device_lookup_private+0x8 device_lookup_private(0xf0335ebc, 0x0, 0x0, 0xf0307000,

Re: Using emap for i386/amd64 early during boot

2010-06-20 Thread Mindaugas Rasiukevicius
Jean-Yves Migeon jeanyves.mig...@free.fr wrote: As I have yet to understand the inner workings of emap, I'd like to know if it is possible to wrap i386_cpu_switch_pmap() around uvm_emap functions, like this: [...] u_int gen = uvm_emap_gen_return(); i386_cpu_switch_pmap(pmap);

Re: Using emap for i386/amd64 early during boot

2010-06-20 Thread Mindaugas Rasiukevicius
Jean-Yves Migeon jeanyves.mig...@free.fr wrote: I know that a lot of legacy code uses the preprocessor the way that you have in i386_cpu_switch_pmap(), but I don't think that the preprocessor should be used in that way any longer. In my experience, code that uses the preprocessor

Re: Using emap for i386/amd64 early during boot

2010-06-22 Thread Mindaugas Rasiukevicius
Jean-Yves Migeon jeanyves.mig...@free.fr wrote: Agree with David's point, but it should not be done at function level. Rather higher level interface abstraction. In uvmplock branch, I have already split some x86 pmap bits into pmap_tlb.c and xen_pmap.c modules. More interfaces can be

Re: Move the vnode lock into file systems

2010-06-29 Thread Mindaugas Rasiukevicius
David Holland dholland-t...@netbsd.org wrote: Vaguely related to which, does anyone object to wrapping VOP_UNLOCK in a vn_unlock() function (doing nothing extra), so as to be symmetric with vn_lock()? I think I've mentioned this before, but I'm not sure, and if so it was a while back... I

Re: Select broken in current?

2010-07-10 Thread Mindaugas Rasiukevicius
Martin Husemann mar...@duskware.de wrote: I just updated my machine to latest -current as of yesterday and noticed mpg123 from pkgsrc stopped working. It uses a child process to buffer audio output (19007 in the ktrace below) and when that is ready, it tells the parent to proceed with the

Re: binary plist support

2010-07-13 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: hi, what's the status of this? YAMAMOTO Takashi I would welcome bplist support too. # Jason Thorpe 2007-10-16: [... comments on previous version ...] I'm done with (hopefully) final version:

Re: The missing membar_X() directive

2010-07-14 Thread Mindaugas Rasiukevicius
matthew green m...@eterna.com.au wrote: RCU patent expires in 25 months, right? soon we don't have to care, regardless of the jurisdiction. There is code for passive serialization, which is similar technique. -- Mindaugas

Re: Module and device configuration locking [was Re: Modules loading modules?]

2010-08-06 Thread Mindaugas Rasiukevicius
Hello, Paul Goyette p...@whooppee.com wrote: Well, it was a slow day at the office today, so I found some time to work on this! :) Attached is the latest version of this change. For simplicity, I have broken the patches up into five separate groups: ... Few comments on the patch:

Re: Module and device configuration locking [was Re: Modules loading modules?]

2010-08-08 Thread Mindaugas Rasiukevicius
Paul Goyette p...@whooppee.com wrote: Following up on all the various comments from jmcneil@, pooka@, and rmind@, I've attached a revised set of diffs. The most significant change between this and the previous revision is the separation of the kernconfig_lock_*() stuff into a separate

Re: 16 year old bug

2010-08-24 Thread Mindaugas Rasiukevicius
Matt Thomas m...@3am-software.com wrote: On Aug 24, 2010, at 12:25 AM, Joerg Sonnenberger wrote: On Mon, Aug 23, 2010 at 11:21:37PM -0400, Thor Lancelot Simon wrote: That's silly. A bitmask is a bitmask, and there's nothing magical or difficult about masked compare. Even the bug

Converting to condvar(9) [Was: Re: CVS commit: src/sys/dev/ieee1394]

2010-09-05 Thread Mindaugas Rasiukevicius
Christoph Egger christoph_eg...@gmx.de wrote: Log Message: don't call tsleep() with any mutexes hold To generate a diff of this commit: cvs rdiff -u -r1.23 -r1.24 src/sys/dev/ieee1394/fwdev.c The right fix would be to use condvar(9). Generally, tsleep(9) should be replaced and

Re: XIP

2010-11-02 Thread Mindaugas Rasiukevicius
Chuck Silvers c...@chuq.com wrote: - in getpages, rather than allocating a page of zeros for each file, it would be better to use the same page of zeroes that mem.c uses. if multiple subsystems need a page of zeroes, then I think that UVM should provide this functionality

Re: XIP

2010-11-05 Thread Mindaugas Rasiukevicius
Masao Uebayashi uebay...@tombi.co.jp wrote: Those mechanical vm_page - vm_page_md changes done in pmaps have a valid point by itself. Passing around vm_page pointer across pmap functions is unnecessary. I'd rather say wrong. All pmap needs is vm_page_md. I'd propose to do

Re: AMAP_SHARED (was Re: XIP)

2010-11-05 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: iirc, you need minherit to create shared-cow mappings. (imo, the introduction of minherit was a mistake because it merely complicated vm.) I think we should look for a way to remove it. YAMAMOTO Takashi -- Mindaugas

Re: Getting rid of standard boiler plate in kernel man pages CODE REFERENCES

2010-11-08 Thread Mindaugas Rasiukevicius
Thomas Klausner w...@netbsd.org wrote: Many many many kernel (section 9) man pages contain the following sentence in their CODE REFERENCES section: This section describes places within the .Nx source tree where actual code implementing .Nm can be found. All pathnames are relative to

Re: Getting rid of standard boiler plate in kernel man pages CODE REFERENCES

2010-11-08 Thread Mindaugas Rasiukevicius
Paul Goyette p...@whooppee.com wrote: How about: [...] +Any paths are relative to the top level of the source tree (usually +.Pa /usr/src ) . Sounds fine. Or perhaps historically instead of usually :) Or often might work, too. No opinion on that :-) typically or

Re: mutexes, locks and so on...

2010-11-12 Thread Mindaugas Rasiukevicius
Andrew Doran a...@homeworld.netbsd.org wrote: bqt, wanna start a fork? Looks as though NetBSD no longer supports most of the architectures it used to. That idea could have merit. Indeed.. -- Mindaugas

Re: mutexes, locks and so on...

2010-11-12 Thread Mindaugas Rasiukevicius
Antti Kantee po...@cs.hut.fi wrote: On Fri Nov 12 2010 at 14:30:58 +0100, Johnny Billquist wrote: By reasoning that we should design for tomorrows hardware, we might as well design explicitly for x86_64, and let all other emulate that. But in the past, I believe NetBSD have tried to raise

Re: mutexes, locks and so on...

2010-11-12 Thread Mindaugas Rasiukevicius
der Mouse mo...@rodents-montreal.org wrote: Decision was to provide CAS abstraction [sic!] as a primitive for MI, by the MD land - in a same way, like we have copy(9), fetch(9), store(9) or many other means, just in this case MI asks MD to ensure atomicity. It was relevant to make a

Re: assertion spc-spc_migrating == NULL failed

2010-11-23 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: (The soft int may vary). Looking at the sources, I see that sched_nextlwp() is carefull to not propose a new lwp if a migration is in progress. But when this KASSERT fires we're not necesserely about to switch to a new (non-idle) lwp, but

Re: vmpage race and deadlock

2010-11-28 Thread Mindaugas Rasiukevicius
Juergen Hannken-Illjes hann...@eis.cs.tu-bs.de wrote: Some weeks ago I started my fs stress test (5 x fsstress+fsx+dbench) on a log enabled ffs1 file system backed by md(4). Usually within hours I get a deadlock where a thread is waiting on genput but the page in question is neither BUSY nor

Re: Multiple interlocks on the same condvar(9)

2011-01-11 Thread Mindaugas Rasiukevicius
Grégoire Sutre gregoire.su...@gmail.com wrote: With condvar(9), is it possible to have different LWPs waiting on the same cv, but with different interlocks? Short answer: no, and that generally does not make sense. Interlock is supposed to protect the state and the condition. You achieve the

Re: kernel memory allocators

2011-01-19 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: Benefits I've thought about: - The kmem pools use pool_caches therefor scalability will be much better as the old malloc has a single lock for all access, the pools have one each with a per cpu cache layer. - The old malloc only returns

Per-CPU Unit (PCU) interface

2011-01-24 Thread Mindaugas Rasiukevicius
Hello, While looking at the bugs on still work-in-progress mips64 FPU code on Matt's branch, it occurred to me that we could abstract SMP handling complexity into MI interface. Basically, all architectures are using similar logic for FPU handling on SMP, but each have own variations, confusions,

Re: Per-CPU Unit (PCU) interface

2011-01-25 Thread Mindaugas Rasiukevicius
Martin Husemann mar...@duskware.de wrote: I can't make up my mind if this is a complication or proper abstraction. Assuming it is only used for lazy FPU saving and an arch does not have other PCU needs, it overall does not save a lot of work. ... Apart from fixing the bugs (which I have

Re: Per-CPU Unit (PCU) interface

2011-01-25 Thread Mindaugas Rasiukevicius
Andrew Doran a...@netbsd.org wrote: http://www.netbsd.org/~rmind/subr_pcu.c http://www.netbsd.org/~rmind/pcu.h http://www.netbsd.org/~rmind/pcu.diff I have three problems with this: - It uses our xcall interface which provides a mailbox to pass messages between CPUs. The intent

Re: next vforkup chapter: lwpctl

2011-02-17 Thread Mindaugas Rasiukevicius
Garrett Cooper yaneg...@gmail.com wrote: But what, that uses LWPCTL, are you actually supposed to be doing after vfork()?  Whack some environment variables and some globals -- maybe -- then exec*().  What else is legitimate? If it doesn't slow down vfork, great, fix whatever.  But

Re: Status and future of 3rd party ABI compatibility layer

2011-03-01 Thread Mindaugas Rasiukevicius
Joerg Sonnenberger jo...@britannica.bec.de wrote: there is a lot of code in sys/compat and changes in the kernel API tend to require changes in this code too. I would like to know which emulations are actually in use, what the status of emulation is (both in terms of stability and feature set)

Re: Decomposing vfs_subr.c

2011-03-23 Thread Mindaugas Rasiukevicius
Andrew Doran a...@netbsd.org wrote: I would like to split-off parts of vfs_subr.c into vfs_node.c * and vfs_mount.c modules. Decomposing should hopefully bring some better abstraction, as well as make it easier to work with VFS subsystem. Any objections? Sounds good to me. Some

Re: inheriting the lwp private area

2011-03-23 Thread Mindaugas Rasiukevicius
Andrew Doran a...@netbsd.org wrote: You mean l-l_private should be copied on fork? Absolutely. For native fork I agree, but that's probably not the right thing to do if FORK_SHARESIGS or whatever it's called (i.e. clone()ing off a Linux-style thread). (Some day I hope we can emulate

Re: Decomposing vfs_subr.c

2011-03-23 Thread Mindaugas Rasiukevicius
David Holland dholland-t...@netbsd.org wrote: - I think it should be vfs_vnode.c? OK, unless somebody will come up with a better name. Since AIUI from chat this is going to contain the vnode lifecycle and code and not e.g. stuff like vn_lock, I think I'd prefer vfs_vncache.c.

Re: high sys time, very very slow builds on new 24-core system

2011-03-25 Thread Mindaugas Rasiukevicius
Andrew Doran a...@netbsd.org wrote: We have some algorhythms in the scheduler and mutual exclusion code that aren't designed for large numbers of cores, but I think they should be OK with 24 CPUs. ... I have committed mutex_oncpu patch, so it is O(1) in -current. ... (While I'm rambling

Re: extent-patch and overview of what is supposed to follow

2011-04-01 Thread Mindaugas Rasiukevicius
Hello Lars, Lars Heidieker l...@heidieker.de wrote: this is a part of the changes to the kernel memory management. It's a changing the subr_extent to use kmem(9) instead of malloc(9) essentially removing the MALLOC_TYPE from it. Why start from this end, instead of converting extent(9) uses to

Re: extent-patch and overview of what is supposed to follow

2011-04-05 Thread Mindaugas Rasiukevicius
Manuel Bouyer bou...@antioche.eu.org wrote: Just an Idea, how about giving the kmem allocator a pool like logging... or malloc(9)-like :) :-) The trouble is large parts of the kernel are migrated to kmem already and having too interfaces and two allocators is something that

Re: GSoC 2011 project proposal [Add kqueue support to GIO]

2011-04-05 Thread Mindaugas Rasiukevicius
Jean-Yves Migeon jeanyves.mig...@free.fr wrote: On 03.04.2011 23:10, Mindaugas Rasiukevicius wrote: Solaris has Event Port interface, an equivalent of inotify, which has mentioned capabilities. I would suggest to evaluate its interface: Isn't it approximately like what filemon(4) does

Re: extent-patch and overview of what is supposed to follow

2011-04-06 Thread Mindaugas Rasiukevicius
Manuel Bouyer bou...@antioche.eu.org wrote: On Tue, Apr 05, 2011 at 10:37:37AM +0100, Mindaugas Rasiukevicius wrote: It could be DTrace facility or some __builtin_return_address tracking to have some means e.g. to identify memory leaks when kmem(9) is used. I am not convinced about

Re: extent-patch and overview of what is supposed to follow

2011-04-06 Thread Mindaugas Rasiukevicius
Brett Lymn bl...@baea.com.au wrote: I am not convinced about statistics point. For intensive allocations, constant-sized pool_cache(9) should/would be used, where it already gathers statistics. If there is some particular need for statistics, one can always collect it at the caller's

Re: extent-patch and overview of what is supposed to follow

2011-04-06 Thread Mindaugas Rasiukevicius
Lars Heidieker l...@heidieker.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/11 02:31, Mindaugas Rasiukevicius wrote: I think it would be better to convert malloc(9) to kmem(9) where possible before the merger. So we could better see what is left i.e. what memory

Re: extent-patch and overview of what is supposed to follow

2011-04-06 Thread Mindaugas Rasiukevicius
Manuel Bouyer bou...@antioche.eu.org wrote: ... - I'm not sure you want to have dtrace running on a production server. KMEMSTATS is more than pure debugging purpose, it also helps with tuning, and figuring out temporary overload. DTrace was *designed* as suitable for production systems. It

Re: kmem-pool-uvm

2011-04-09 Thread Mindaugas Rasiukevicius
Lars Heidieker l...@heidieker.de wrote: The patch provided includes the changed extent as well as a changed implementation of kmem, which provides page aligned memory for allocation = PAGE_SIZE. The interface between the pool-subsystem and uvm_km is changed by passing the pool_allocators

Merge of rmind-uvmplock branch

2011-05-31 Thread Mindaugas Rasiukevicius
Hello, Unless anyone objects, I will merge rmind-uvmplock branch. The technical objectives of the branch are described here: http://nxr.netbsd.org/xref/src/doc/BRANCHES?r=1.307#488 This results in: - Rewritten x86 TLB handler, which is simpler and cleaner C code. - UVM provides extra

Re: Merge of rmind-uvmplock branch

2011-06-08 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: Unless anyone objects, I will merge rmind-uvmplock branch. The technical objectives of the branch are described here: http://nxr.netbsd.org/xref/src/doc/BRANCHES?r=1.307#488 the idea is to protect pv chains with object lock, right? is

Re: kmem-pool-uvm

2011-06-08 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: Yes it does, it switches to cache_line size for alignment for allocations = cache_line size and to page_size alignment for allocations = page_size. kmem_alloc(9F) says: The allocated memory is at least double-word aligned, so it

Re: kmem-pool-uvm

2011-06-08 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: let me explain some background. currently there are a number of kernel_map related problems: A-1. vm_map_entry is unnecessarily large for KVA allocation purpose. A-2. kernel-map-entry-merging is there to solve A-1. but it introduced

Re: Merge of rmind-uvmplock branch

2011-06-13 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: the idea is to protect pv chains with object lock, right? is the new locking protocol documented anywhere? Right, object associated with the page (UVM object or anon). That can be asserted by pmaps using a new uvm_page_locked_p()

Re: uvm locking inconsistency

2011-06-15 Thread Mindaugas Rasiukevicius
Matthias Drochner m.droch...@fz-juelich.de wrote: A fresh kernel panics for me with a KASSERT about a lock not held - see attachment. uvm_pgalloc() was called from amap_cow_now() -- the anon is freshly allocated, so the reason for the panic is obvious. (and it seems better to relax the

Re: diagnostic assertion anon-an_lock == amap-am_lock

2011-06-16 Thread Mindaugas Rasiukevicius
dieter roelants dieter.net...@pandora.be wrote: On an amd64 kernel with DIAGNOSTIC and LOCK_DEBUG enabled, the following assertion got triggered while building packages: anon-an_lock == amap-am_lock in sys/uvm/uvm_fault.c line 1228 My kernel dates from yesterday evening, including

Re: uvm locking inconsistency

2011-06-16 Thread Mindaugas Rasiukevicius
Manuel Bouyer bou...@antioche.eu.org wrote: Contrary, I think every viable debug option (DIAGNOSTIC + LOCKDEBUG at least) should be enabled in HEAD, but disabled in release kernels. An easy way to catch obvious regression that should never enter a release kernel. The so-called HEAD is

Re: add DIAGNOSTIC back to GENERIC/INSTALL

2011-06-16 Thread Mindaugas Rasiukevicius
Manuel Bouyer bou...@antioche.eu.org wrote: for the second time (at last) a kernel issue raised the question of adding back 'options DIAGNOSTIC' to GENERIC/INSTALL kernels in HEAD. Several people agreed tha this would be a good thing. So here's the formal question: would someone object if I

Re: add DIAGNOSTIC back to GENERIC/INSTALL

2011-06-16 Thread Mindaugas Rasiukevicius
Mindaugas Rasiukevicius rm...@netbsd.org wrote: I have few concerns: - If we enable DIAGNOSTIC, then we should also enable DEBUG, as it also covers many relevant diagnostic checks. - Alternatively, it should be clearly defined what goes under DEBUG, i.e. what is considered a heavier

Re: kprempt, pmap_load() and copy*

2011-06-19 Thread Mindaugas Rasiukevicius
Manuel Bouyer bou...@antioche.eu.org wrote: Hmmm lets see... thinks ... copyin/out can fault or be interrupted, both can cause a process switch. So there ought to be code somewhere (probably in the return from trap/intr code) that will restore the pmap to allow the copy to continue.

Re: [FIXED] diagnostic assertion anon-an_lock == amap-am_lock

2011-06-27 Thread Mindaugas Rasiukevicius
dieter roelants dieter.net...@pandora.be wrote: On an amd64 kernel with DIAGNOSTIC and LOCK_DEBUG enabled, the following assertion got triggered while building packages: anon-an_lock == amap-am_lock in sys/uvm/uvm_fault.c line 1228 I think hannken@ and yamt@ fixed the bugs here. Please try.

Re: add DIAGNOSTIC back to GENERIC/INSTALL

2011-07-03 Thread Mindaugas Rasiukevicius
Manuel Bouyer bou...@antioche.eu.org wrote: - Obviously, defined policy/responsibility to disable these options for release kernels. In fact, if we go this way - then options should be removed from all MD kernel configs and managed in MI src/sys/conf/std. I'm not sure this is

Re: add DIAGNOSTIC back to GENERIC/INSTALL

2011-07-03 Thread Mindaugas Rasiukevicius
Manuel Bouyer bou...@antioche.eu.org wrote: On Sun, Jul 03, 2011 at 04:17:02PM +0100, Mindaugas Rasiukevicius wrote: Manuel Bouyer bou...@antioche.eu.org wrote: - Obviously, defined policy/responsibility to disable these options for release kernels. In fact, if we go this way

kcpuset(9) interface

2011-07-31 Thread Mindaugas Rasiukevicius
Hello, Here is a reworked dynamic CPU set implementation for kernel (shared cpuset.c in src/common will be moved to libc) - a kcpuset(9) interface: http://www.netbsd.org/~rmind/kcpuset_ng.diff It supports early use while the system is cold through a fix up mechanism, see kcpuset_sysinit().

Re: kcpuset(9) interface

2011-08-02 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: Here is a reworked dynamic CPU set implementation for kernel (shared cpuset.c in src/common will be moved to libc) - a kcpuset(9) interface: http://www.netbsd.org/~rmind/kcpuset_ng.diff It supports early use while the system is cold

Re: kcpuset(9) interface

2011-08-07 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: why did you change kcpuset_t to a pointer from a structure? i always feel awkward to compare an opaque type with NULL. The reason is that kcpuset_t now points directly to the bit field rather than opaque struct kcpuset_impl. Do you

Re: wrapping (some) ipis in arch/x86/

2011-08-13 Thread Mindaugas Rasiukevicius
chris...@astron.com (Christos Zoulas) wrote: In article 8762m4qlm8@zyx.in, Cherry G. Mathew che...@zyx.in wrote: ftp://ftp.netbsd.org/pub/NetBSD/misc/cherry/tmp/wrap_ipi.diff Hi, I'd like to ask peoples' opinions about the above patch. This would remove a couple of #ifdef XEN/#endif

Re: Adding pulse support to gpio(4), gpioctl(8)

2011-08-23 Thread Mindaugas Rasiukevicius
Marc Balmer mbal...@netbsd.org wrote: There is nothing what prevents from multiple threads calling gpioioctl (), which is obviously not MP-safe. As soon as you will start fixing this, it will bring you back to the point I have already stated - the design needs to be MP-safe in general.

Re: panic with 5.99.55 starting postgres

2011-08-27 Thread Mindaugas Rasiukevicius
Darren Reed darr...@netbsd.org wrote: starting postgres panic's my system every time with this panic: panic: kernel diagnostic assertion uvm_page_locked_p(pg e ../../../../arch/x86/x86/pmap.c, line 3214 And perhaps more importantly, does anyone know when and where this was

Re: Adding pulse support to gpio(4), gpioctl(8)

2011-08-28 Thread Mindaugas Rasiukevicius
Mouse mo...@rodents-montreal.org wrote: Multiple threads can ioctl and nobody prevents one from having a single process with multiple threads (pthreads, if you like). Not only that, but even without threading, there are at least two ways I can think of offhand that a file descriptor, once

Re: Some kernel void functions do return a value

2011-10-15 Thread Mindaugas Rasiukevicius
Nicolas Joly nj...@pasteur.fr wrote: [213] /local/src/NetBSD/src/sys/kern/subr_vmem.c(1070): void function vmem_free cannot return value [213] /local/src/NetBSD/src/sys/kern/subr_vmem.c(210): void function xfree cannot return value [213] Fixed these. -- Mindaugas

Re: May pool_cache_get() ever return NULL?

2011-10-15 Thread Mindaugas Rasiukevicius
Jean-Yves Migeon jeanyves.mig...@free.fr wrote: On Thu, 6 Oct 2011 09:50:18 +0200, J. Hannken-Illjes wrote: A short question: Given a pool initialized with pool = pool_cache_init(SIZE, 0, 0, 0, desc, NULL, IPL_NONE, NULL, NULL, NULL); will pool_cache_get(pool,

Re: Some kernel void functions do return a value

2011-10-15 Thread Mindaugas Rasiukevicius
David Young dyo...@pobox.com wrote: This isn't just a lint bug? At least two of these are instances of void functions returning the return value of a void function, for which the compiler need neither throw away a value nor create one from whole nothing. The compiler doesn't

Re: aio rework

2011-10-16 Thread Mindaugas Rasiukevicius
Alexander Nasonov al...@yandex.ru wrote: One possible solution is using separate threads for reading and writing. It's a bit of work but it looks quite straitforward and I can do it at my spare time. Even with two threads, aio implementation is not optimal but I don't have enough knowledge

Re: kmem-pool-uvm

2011-11-02 Thread Mindaugas Rasiukevicius
Hello Lars, Sorry for late reply. Lars Heidieker l...@heidieker.de wrote: i uploaded a new version of the kmem-pool-vmem-uvm patch: ftp://ftp.netbsd.org/pub/NetBSD/misc/para/kmem-pool-vmem-uvm.patch ... I've uploaded a new Version of the patch and a small patch that replaces malloc

Re: VOP_GETATTR: locking protocol change proposal

2011-11-17 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: ... With the attached diff the locking protocol requests at least a shared lock and all calls to VOP_GETATTR() outside of file systems respect it. ... postgresql assumes instant lseek(SEEK_END) to get the size of their heap files.

Re: pool_cache_invalidate(9) (wrong?) semantic -- enable xcall invalidation

2011-11-17 Thread Mindaugas Rasiukevicius
Jean-Yves Migeon jeanyves.mig...@free.fr wrote: On 25.09.2011 01:50, Jean-Yves Migeon wrote: I would like to turn back on the xcall(9) block found in pool_cache_invalidate(), now that rmind@ has implemented high priority cross calls [1]. FWIW, I am still struggling with this, without

Re: VOP_GETATTR: locking protocol change proposal

2011-11-20 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: postgresql assumes instant lseek(SEEK_END) to get the size of their heap files. http://rhaas.blogspot.com/2011/11/linux-lseek-scalability.html as fsync etc keeps the vnode lock during i/o, it might cause severe performance

Re: Importing chewiefs

2011-11-23 Thread Mindaugas Rasiukevicius
chris...@astron.com (Christos Zoulas) wrote: I think that we should choose a more descriptive name for it. Having cute project names is good during development, but we need meaningful names for posterity that make sense to people. Imagine if we had named nfs cutefs, ffs kirkfs, etc. Seconded.

Re: SHMMAX runtime setting for Postgres Installation

2011-11-24 Thread Mindaugas Rasiukevicius
Joerg Sonnenberger jo...@britannica.bec.de wrote: On Thu, Nov 24, 2011 at 04:57:39PM +0100, Emmanuel Kasper wrote: Is that Postgres Documentation outdated ? kern.ipc.shmmax should be adjustable since NetBSD 5.0. It wasn't before. Right, however kern.ipc.shmmaxpgs was adjustable in NetBSD

Re: emap

2011-11-24 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: hi, what's the status of emap and pipe? If I remember correctly, I could not get real performance improvement of pipe with UVM emap. Higher chances are that it would improve socket performance. Also, pipe has direct I/O disabled

Re: SHMMAX runtime setting for Postgres Installation

2011-12-03 Thread Mindaugas Rasiukevicius
Emmanuel Kasper emman...@libera.cc wrote: Le 24/11/2011 19:21, Eric Haszlakiewicz a écrit : On Thu, Nov 24, 2011 at 04:57:39PM +0100, Emmanuel Kasper wrote: Is that Postgres Documentation outdated ? Yes. If you have a few minutes, it would be great if you could submit a request with

Re: heads-up: IPSEC is now FAST_IPSEC

2012-01-14 Thread Mindaugas Rasiukevicius
Matthias Drochner m.droch...@fz-juelich.de wrote: I've just made FAST_IPSEC the default implementation which gets used if the IPSEC kernel option is present. ... The old KAME implementation is still available through the KAME_IPSEC kernel option. The old IPSEC_ESP option is meaningless

Re: Equivalent of FreeBSD kernel semaphore?

2012-01-14 Thread Mindaugas Rasiukevicius
m...@netbsd.org (Emmanuel Dreyfus) wrote: Christos Zoulas chris...@astron.com wrote: Why don't you implement them the same way like FreeBSD did, using a mutex and a condition variable? I am not sure I correctly understand what you mean: is it that we do not have an equivalent of

Re: Define static kmutex_t

2012-01-15 Thread Mindaugas Rasiukevicius
m...@netbsd.org (Emmanuel Dreyfus) wrote: Another DAHDI porting caveat. They use stuff like this to define a static kmutex_t outside any function: static DEFINE_SPINLOCK(pseudo_free_list_lock); NetBSD needs to do this in order to initialize a mutex: static kmutex_t

Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)

2012-01-17 Thread Mindaugas Rasiukevicius
David Holland dholland-t...@netbsd.org wrote: On Mon, Jan 16, 2012 at 10:28:57PM +0100, Manuel Bouyer wrote: I consider lfs second-class citizen at this time and if forward compat if broken for the lfs module on the branch it's probably not a big deal). I don't consider that

Re: kmem-pool-uvm

2012-01-22 Thread Mindaugas Rasiukevicius
Lars Heidieker l...@heidieker.de wrote: I've uploaded a new version of the kmem-pool-vmem-uvm patch: ftp://ftp.netbsd.org/pub/NetBSD/misc/para/kmem-pool-vmem-uvm.patch It incorporates some enhancements and makes the talked about interrupt safe version private to malloc(9) and fixes the leakage

Re: updated patch Re: buffer cache ufs changes (preliminary ffsv2 extattr support)

2012-01-25 Thread Mindaugas Rasiukevicius
matthew green m...@eterna.com.au wrote: David Holland dholland-t...@netbsd.org wrote: On Mon, Jan 16, 2012 at 10:28:57PM +0100, Manuel Bouyer wrote: I consider lfs second-class citizen at this time and if forward compat if broken for the lfs module on the branch it's probably not

Re: UVM patch for PR port-xen/45975

2012-02-18 Thread Mindaugas Rasiukevicius
Chuck Silvers c...@chuq.com wrote: - it would be better to remove the mappings before freeing the page on all platforms, not just xen. that's just a good practice. if you're concerned about a potential performance impact, you could process the pages in batches of 16 or so using a

Re: UVM patch for PR port-xen/45975

2012-02-18 Thread Mindaugas Rasiukevicius
Manuel Bouyer bou...@antioche.eu.org wrote: On Sat, Feb 18, 2012 at 10:12:36AM -0800, Chuck Silvers wrote: On Sat, Feb 18, 2012 at 07:01:24PM +0100, Manuel Bouyer wrote: - the calls to pmap_update() should be moved along with the calls to pmap_kremove(). But not all

Re: MI non-interlocked atomic ops?

2012-02-18 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: which spends (on x86) a small but not immeasurable amount of time in splx(s), so I was tempted to rewrite it like this: void mbstat_type_add(int type, int diff) { struct mbstat_cpu *mb;

Re: O-A loan

2012-02-18 Thread Mindaugas Rasiukevicius
y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote: hi, i'd like to to either fix or remove O-A page loaning. the biggest problem is the lack of users. thus no way to test. any ideas? After looking at O-A loaning code in yamt-pagecache branch, looking at the benchmark results by Jaime (some

Re: UVM patch for PR port-xen/45975

2012-02-18 Thread Mindaugas Rasiukevicius
Manuel Bouyer bou...@antioche.eu.org wrote: On Sat, Feb 18, 2012 at 07:49:13PM +, Mindaugas Rasiukevicius wrote: [...] I also implemented the idea of removing the mappings and freeing page in batch of 16 entries. Updated patch attached, I'm re-running the build.sh -jx release

  1   2   3   >