Date: Tue, 5 Apr 2011 19:00:24 -0700 From: Israel Jacques <mrkotfw@gmail.com> To: freebsd-hackers@freebsd.org Subject: GSoC: Avoiding syscall overhead Message-ID: <BANLkTindyf7p5aKnV7Y_WvMrKAvw6sC-tw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hello, I have sent a copy to one of the people listed as technical support (atillio@). My name is Israel Jacques and I'm an undergrad at the University of California, Berkeley. I am interested in working on removing overhead from the 'SETPROCTITLE(3)' library routine. I see that in the ideas page work has already begun to make this optimization. However, searching through the mailing lists I have not found much discussion on it. After looking through the archives (see references), I have some (crude) high level ideas as to how to approach the problem. The idea, as suggested is to have a shared page between the kernel and a userland process. Having such a shared page would avoid having to invoke sysctl() which causes a the large overhead of a context switch. The shared page 1. needs to be pinned as to avoid having it be paged out. 2. needs to stay alive for the entire duration of the process. 3. needs to be unique for every process. Initially, I was thinking that a shared page should be created for ALL processes, but that would expose vital information to all other processes. Furthermore, any other process can alter the information of another process. As suggested in [9], allocating memory and reserving some region of the process address space, pinning it, and setting the correct page permissions (permissions in the PTE?) would be enough to create such a shared page. Though, letting the process know of this page would require a system call. Again, suggested in reference [9] would add a section in the ELF which would then have a global variable of (potentially) a pointer to a struct with the process information. Of course, a process could mistakenly use the pointer to access outside the bounds of the page and cause trouble. Furthermore, checks need to be made to insure that the process itself doesn't corrupt the information in the struct. Also, for every access a mutex would be needed as to avoid possible race conditions between both the kernel and the process. I'll be looking to go through: src/sys/vm src/lib/libc/gen/setproctitle.c src/sys/kern/sysv_shm.c ...and the VM portion of the "4.4BSD" book. (I just received my FreeBSD book today!) References: [1] http://lists.freebsd.org/pipermail/freebsd-hackers/2009-October/029750.html [2] http://lists.freebsd.org/pipermail/freebsd-performance/2006-June/002038.html [3] http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/029983.html [4] http://lists.freebsd.org/pipermail/freebsd-stable/2008-January/039392.html [5] http://lists.freebsd.org/pipermail/freebsd-performance/2008-January/003107.html [6] http://lists.freebsd.org/pipermail/freebsd-hackers/2008-March/023875.html [7] http://lists.freebsd.org/pipermail/freebsd-hackers/2005-November/014452.html [8] http://lists.freebsd.org/pipermail/freebsd-hackers/2011-February/034419.html [9] http://lists.freebsd.org/pipermail/freebsd-hackers/2005-November/014453.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTindyf7p5aKnV7Y_WvMrKAvw6sC-tw>