From 6ec83083843332b8285957ad5b195db2c90ee5d8 Mon Sep 17 00:00:00 2001 From: dillon Date: Fri, 19 Mar 2010 22:18:19 -0700 Subject: [PATCH] --- docs/developer/gsoc2010/index.mdwn | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/docs/developer/gsoc2010/index.mdwn b/docs/developer/gsoc2010/index.mdwn index 4ad9d524..71039345 100644 --- a/docs/developer/gsoc2010/index.mdwn +++ b/docs/developer/gsoc2010/index.mdwn @@ -43,8 +43,8 @@ and the same data gets cached multiple times wasting precious RAM space. The goal of this project is to add a data de-duplication mechanism to the HAMMER filesystem. A reasonable approach would be to detect potential data matches using CRCs during pruning runs. Then you could verify there is actual duplication of data -(i.e. the match is not a false positive), collapse the B-Tree reference and account for the -additional reference in the allocator. +(i.e. the match is not a false positive), collapse the B-Tree data reference and account for the +additional reference in the allocation blockmap. Meta information: @@ -56,11 +56,12 @@ Meta information: ##### Implement i386 32-bit ABI for x86_64 64-bit kernel * Add a 32-bit syscall table which translates 32-bit - system calls to 64-bit - + system calls to 64-bit. * Add support for 32 bit compatibility mode operation and ELF binary detection. +The idea here is to support the execution of 32 bit DragonFly binaries in 64 bit DragonFly environments, something numerous other operating systems have done. Three things must be done to support this. First, the appropriate control bits must be set to execute in 32-bit compatibility mode while in usermode instead of 64-bit mode. Second, when a system call is made from 32-bit mode a translation layer is needed to translate the system call into the 64-bit requivalent within the kernel. Third, the signal handler and trampoline code needs to operate on the 32-bit signal frame. + Meta information: * Prerequisites: C @@ -69,14 +70,26 @@ Meta information: --- -##### Implement ARC algorithm for vnode free list +##### Implement ARC algorithm extension the vnode free list * Vnode recycling is LRU and can't efficiently handle data sets which - exceed the maxvnode limit. + exceed the maxvnode limit. When the maxvnode limit is reached the kernel + starts throwing away cached vnodes along with their VM objects (and thus + all related cached file data). + +* What we would like to do is implement an ARC algorithm for the free + vnodes to determine which ones to throw away and potentially combine + this with further caching of the related VM object even after the vnode + is thrown away by associating it with a mount point and inode number, + until memory pressure forces all of its pages out. + +* For this project the student can choose to just implement the VM object + retention portion and not try to implement an ARC algorithm (which can + be considerably more complex). Meta information: * Prerequisites: C, OS internals -* Difficulty: Modest +* Difficulty: Modest without ARC (Very difficult with ARC) * Contact point: dillon --- -- 2.41.0