CVS log for src/sys/rump/librump/rumpkern/locks_up.c

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
Branch: MAIN
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
Branch: MAIN
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
Branch: MAIN
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
Branch: MAIN
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

implement mutex_owner()

Revision 1.4 / (download) - annotate - [select for diffs], Mon Jun 14 21:04:56 2010 UTC (2 years, 11 months ago) by pooka
Branch: MAIN
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
Branch: MAIN
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
Branch: MAIN
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: MAIN
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.

Diffs between
and

CVSweb <webmaster@jp.NetBSD.org>

Preferred Diff type:
View only Branch:
Sort log by: