Up to [cvs.NetBSD.org] / src / sys / rump / librump / rumpkern
Request diff between arbitrary revisions
Default branch: MAIN
Current tag: MAIN
Revision 1.9 / (download) - annotate - [select for diffs], Mon May 6 16:28:17 2013 UTC (12 days, 15 hours ago) by pooka
CVS Tags: khorben-n900, HEAD
Changes since 1.8: +6 -3 lines
Diff to previous 1.8 (colored)
update for new hypercalls
Revision 1.8 / (download) - annotate - [select for diffs], Sun Apr 28 13:37:52 2013 UTC (2 weeks, 6 days ago) by pooka
Changes since 1.7: +5 -11 lines
Diff to previous 1.7 (colored)
Change rumpuser_cv_timedwait() from absolute time to relative time. It's then the hypervisor's problem to translate it accordingly. Now we no longer have to worry about the kernel having to know the hypervisor's time and vice versa.
Revision 1.7 / (download) - annotate - [select for diffs], Sat Apr 27 13:59:46 2013 UTC (3 weeks ago) by pooka
Changes since 1.6: +9 -2 lines
Diff to previous 1.6 (colored)
Try to make sure that the appropriate calls to mutex_enter() takes a spin mutex (i.e. does not relinquish cpu context while trying to take the mutex). Bump the hypercall interface version number. I'll be doing a bunch of other cleanups to simplify the interface for the benefit of alternative hypervisor implementations. I'll be riding this bump and doing a second one only after I'm finished with all of the changes.
Revision 1.6 / (download) - annotate - [select for diffs], Sat Apr 28 18:04:02 2012 UTC (12 months, 2 weeks ago) by stacktic
CVS Tags: yamt-pagecache-base8, yamt-pagecache-base7, yamt-pagecache-base6, yamt-pagecache-base5, tls-maxphys-nbase, tls-maxphys-base, tls-maxphys, jmcneill-usbmp-base9, jmcneill-usbmp-base10, agc-symver-base, agc-symver
Changes since 1.5: +3 -2 lines
Diff to previous 1.5 (colored)
Fixed build with locks_up.c
Revision 1.5 / (download) - annotate - [select for diffs], Wed Dec 1 17:22:51 2010 UTC (2 years, 5 months ago) by pooka
CVS Tags: yamt-pagecache-base4, yamt-pagecache-base3, yamt-pagecache-base2, yamt-pagecache-base, rmind-uvmplock-nbase, rmind-uvmplock-base, netbsd-6-base, netbsd-6-1-RELEASE, netbsd-6-1-RC4, netbsd-6-1-RC3, netbsd-6-1-RC2, netbsd-6-1-RC1, netbsd-6-0-RELEASE, netbsd-6-0-RC2, netbsd-6-0-RC1, netbsd-6-0-2-RELEASE, netbsd-6-0-1-RELEASE, netbsd-6-0, netbsd-6, matt-nb6-plus-nbase, matt-nb6-plus-base, matt-nb6-plus, matt-mips64-premerge-20101231, jruoho-x86intr-base, jruoho-x86intr, jmcneill-usbmp-pre-base2, jmcneill-usbmp-base8, jmcneill-usbmp-base7, jmcneill-usbmp-base6, jmcneill-usbmp-base5, jmcneill-usbmp-base4, jmcneill-usbmp-base3, jmcneill-usbmp-base2, jmcneill-usbmp-base, jmcneill-audiomp3-base, jmcneill-audiomp3, cherry-xenmp-base, cherry-xenmp, bouyer-quota2-nbase, bouyer-quota2-base, bouyer-quota2
Branch point for: yamt-pagecache, jmcneill-usbmp
Changes since 1.4: +9 -2 lines
Diff to previous 1.4 (colored)
Revision 1.4 / (download) - annotate - [select for diffs], Mon Jun 14 21:04:56 2010 UTC (2 years, 11 months ago) by pooka
CVS Tags: yamt-nfs-mp-base11, yamt-nfs-mp-base10, uebayasi-xip-base4, uebayasi-xip-base3, uebayasi-xip-base2
Branch point for: yamt-nfs-mp, uebayasi-xip
Changes since 1.3: +4 -4 lines
Diff to previous 1.3 (colored)
Make it possible to define an upper limit for memory consumed by the rump kernel by specifying RUMP_MEMLIMIT. In case allocation over that limit is attempted, essentially pool reclaim and uvm_wait() is done. The default is to allow to allocate as much as the host will give. XXX: uvm_km_alloc and malloc(9) do not currently conform. the former is easy, the latter requires kern_malloc.c (rump malloc is currently directly relegated to host malloc).
Revision 1.3 / (download) - annotate - [select for diffs], Thu Jun 3 10:56:20 2010 UTC (2 years, 11 months ago) by pooka
Changes since 1.2: +4 -4 lines
Diff to previous 1.2 (colored)
Implement a sort-of pagedaemon: adjust all memory allocators to go through an in-rumpkernel hypermemory allocator which knows it should kick the pagedaemon and block in case ``waitok'' memory allocation fails. This allows us to recover from some out-of-memory situations. Realworld'istically speaking (as opposed to whatever "should be" theory), these OOM situations will happen extremely rarely if ever when our hypervisor is a regular process. Speculatively, this should be useful for other types of hosts. issues remaining: * the hypervisor does not know how to reclaim kernel memory (and for the reason I stated above, I'm not sure if it makes sense to teach the current implementation about that) * vfs memory (buffers, vm object pages etc.) is not reclaimed
Revision 1.2 / (download) - annotate - [select for diffs], Tue Jun 1 20:11:33 2010 UTC (2 years, 11 months ago) by pooka
Changes since 1.1: +3 -3 lines
Diff to previous 1.1 (colored)
Don't pass "canfail" down to rumpuser_malloc -- there's quite little we can do with that info way down there. Instead, pass alignment. Implement rumpuser_malloc() with posix_memalign().
Revision 1.1 / (download) - annotate - [select for diffs], Tue May 18 16:29:36 2010 UTC (3 years ago) by pooka
Branch point for: rmind-uvmplock
Add uniprocessor versions of mutex/rw/cv. They work only on virtual unicpu configurations (i.e. RUMP_NCPU==1), but are massively faster than the multiprocessor versions since the fast path does not have to perform any cache coherent operations. _Applications_ with lock-happy kernel paths, i.e. _not_ lock microbenchmarks, measure up to tens of percents speedup on my Core2 Duo. Every globally atomic state required by normal locks/atomic ops implies a hideous speed penalty even for the fast path. While this requires a unicpu configuration, it should be noted that we are talking about a virtual unicpu configuration. The host can have as many processors as it desires, and the speed benefit of virtual unicpu is still there. It's pretty obvious that in terms of scalability simple workload partitioning and replication into multiple kernels wins hands down over complicated locking or locklessing algorithms which depend on globally atomic state.
This form allows you to request diff's between any two revisions of a file. You may select a symbolic revision name using the selection box or you may type in a numeric name using the type-in text box.