---
todo/mm | 55 -------------------------------------------------------
todo/mutex | 31 -------------------------------
2 files changed, 86 deletions(-)
delete mode 100644 todo/mm
delete mode 100644 todo/mutex
diff --git a/todo/mm b/todo/mm
deleted file mode 100644
index dd7f1d0..0000000
--- a/todo/mm
+++ /dev/null
@@ -1,55 +0,0 @@
-1. Lazy population
-==================
-
-Currently, an anonymous mmap() allocates physical memory pages for the
-entire specified memory range.
-
-This is similar to MAP_POPULATE in Linux, but is not the default on Linux.
-Rather, its default is lazy population: Physical memory is only allocated
-to pages when they are actually used. The benefit of this can be noticed
-in various places, but one particularly interesting benefit is to threads:
-Each threads mmap()s a 1MB (by default) stack. In OSV's eager population,
-a full 1MB of physical memory is allocated to each thread. With lazy
-population, if a thread only uses 10 KB of its stack (which is not unlikely!),
-only about this much of physical memory is actually allocated.
-
-So OSV should also have lazy population.
-
-Some implementation ideas:
-
-1. Continue to use both small and huge pages, and lazily allocate both.
- I.e., a 1MB stack will get a page fault on every new 4K used, but a
- huge 500MB allocation (e.g., Java's heap) will get page faults that
- clear 2MB at a time.
-
-2. For small pages, consider this approach: Allocate one zeroed 4K page,
- call it page_zero. New mmaps() will be filled with ptes pointing
- to this page_zero, all marked read-only. If the program reads these
- addresses, it gets 0 as expected. When the program writes to such
- an address, we get a page fault. When the page-fault handler sees the
- fault is at an address pointing to page_zero, it allocates a new physical
- page, zeros it ("copy on write") and sets the PTE to point to it (TODO:
- do we need TLB flush here?).
-
-3. For huge pages, especially 1G pages, allocating an unused zero page is a
- waste. Instead, use an arbitrary page address, and mark it non-present
- (not readable, and not writable). On write fault, allocate a new zero
- huge page as before. On read fault, also allocate a zero huge page
- if we haven't done this before, but remember who's using it so we can
- soon "expire" this page and mark all its references not-present again
- (this will definitely require a TLB flush).
-
-Of course, look also at what Linux does here to get ideas.
-
-
-2. mmap() writeback
-===================
-
-Currently, mmap()ing a file reads it into memory once, but if one writes
-to this memory area, the file is NOT written to - not sponteneously and
-not even if you call msync().
-
-This is similar to MAP_PRIVATE in Linux, but is not what people usually
-have in mind when they use mmap. Java has an interface memory-mapping of
-files (see MappedByteBuffer), and its user do expect that data written
-into such mapped memory will be written back the backing file.
diff --git a/todo/mutex b/todo/mutex
deleted file mode 100644
index ca81dbb..0000000
--- a/todo/mutex
+++ /dev/null
@@ -1,31 +0,0 @@
-1. Make the structure smaller
------------------------------
-If we reduce mutex's size (currently 40 bytes) to 36 bytes, and also
-additionally reduce the size of condvar, we can use mutex and condvar
-directly in the pthread implementation instead of lazy_indirect<>.
-
-We shouldn't do this unless there's evidence that lazy_indirect is
-hurting performance.
-
-Some ideas on how to make the structures smaller:
-1. Make sequence, handoff, and/or depth 16-bit (in osv/mutex.h depth is
- already 16-bit).
- Can also make "count" 16-bit, but this will limit the number of waiting
- threads to 65536, so probably not a good idea.
-2. Make queue_mpsc's two pointers 32-bit. On thread creation, give each
- thread a 32-bit pointer (or a recycled thread_id - see below - indexing
- a global array) which can be used instead of putting the wait struct on
- the stack. Or perhaps we can put all stacks in the low 32 bit?
-3. Do the same to the two pointers in condvar to make condvar smaller too,
-4. Have a new recycled low (32-bit) numeric "threadid" and use it for owner
- instead of a 64-bit pointer.
-
-2. Memory ordering
-------------------
-
-Using sequential memory ordering for all atomic variables is definitely
-not needed, and significantly slows down the mutex. I already relaxed the
-memory ordering in the fast path, and saw a significant improvement in
-the uncontended case, but I need to complete this work in the handoff case.
-See the measure_uncontended<handoff_stressing_mutex> for measuring this case
-(currently I see 48 ns instead of 29 ns for the non-handoff case).
--
2.7.4
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
