os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add project about avoiding syscall overhead for some userland requests

Browse source 
such as setproctitle().  Suitable for SoC with right mentor.

Submitted by:	kris
Additional text by:	rwatson
This commit is contained in:
Murray Stokely 2007-03-11 06:58:12 +00:00
parent 69edf26261
commit 181fe4144e
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=29763
1 changed files with 33 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

34
en/projects/ideas/ideas.xml
View file

@ -15,7 +15,7 @@ Ideas//EN"
<ideas>
<cvs:keywords xmlns:cvs="http://www.FreeBSD.org/XML/CVS" version="1.0">
<cvs:keyword name="freebsd">
$FreeBSD: www/en/projects/ideas/ideas.xml,v 1.4 2007/03/10 07:37:44 murray Exp $
$FreeBSD: www/en/projects/ideas/ideas.xml,v 1.5 2007/03/10 10:12:44 joel Exp $
</cvs:keyword>
</cvs:keywords>
@ -630,6 +630,38 @@ be used without kernel symbols to analyze the failure mode.</p>
<ul>
<li>Familiarity with FreeBSD kernel debugging environment.</li>
<li>Ability to write C code.</li>
</ul>
</desc>
</idea>
<idea id="setproctitle" class="soc">
<title>Avoiding syscall overhead</title>
<desc>
<p><strong>Technical contact</strong>: <a href="mailto:kris@FreeBSD.org">Kris Kennaway</a></p>
<p>setproctitle() calls are a serious
performance bottleneck in a default pgsql configuration (they are
called at least once per query, which might be thousands of times per
second - I measured a performance impact of about 33% on sysbench).</p>
<p>One idea for avoiding the syscall (and global sysctl lock) overhead
for this kind of thing would be a memory page shared between kernel
and userland which libc could read/write to access things like the
process title. There are potentially many other data values that
could be optimized by a similar method. This is presumably a well
established technique in other OSes.</p>
<p>This project requires mentoring/review/planning with someone with
significant VM experience to make sure this approach
works properly. Done incorrectly, this could result in fairly
massive security holes, performance issues (perhaps not visible in
simple benchmarks), etc.</p>
<p><strong>Requirements</strong>:</p>
<ul>
<li>Strong knowledge of C.</li>
<li>Understanding of kernel VM.</li>
</ul>
</desc>
</idea>