public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matt Helsley <matthltc@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>,
	Jes Sorensen <jes@sgi.com>, Christoph Hellwig <hch@lst.de>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Steve Grubb <sgrubb@redhat.com>,
	linux-audit@redhat.com, Paul Jackson <pj@sgi.com>
Subject: [PATCH 00/10] Introduction
Date: Thu, 14 Dec 2006 16:07:54 -0800	[thread overview]
Message-ID: <20061215000754.764718000@us.ibm.com> (raw)

This is version 2 of my Task Watchers patches with performance enhancements.

Task watchers calls functions whenever a task forks, execs, changes its
[re][ug]id, or exits.

Task watchers is primarily useful to existing kernel code as a means of making
the code in fork and exit more readable. Kernel code uses these paths by
marking a function as a task watcher much like modules mark their init
functions with module_init(). This improves the readability of copy_process().

The first patch adds the basic infrastructure of task watchers: notification
function calls in the various paths and a table of function pointers to be
called. It uses an ELF section because parts of the table must be gathered
from all over the kernel code and using the linker is easier than resolving
and maintaining complex header interdependencies. Furthermore, using a list
proved to have much higher impact on the size of the patches and was deemed
unacceptable overhead. An ELF table is also ideal because its "readonly" nature means that no locking nor list traversal are required.

Subsequent patches adapt existing parts of the kernel to use a task watcher
 -- typically in the fork, clone, and exit paths:

        FEATURE (notes)                               RELEVANT CONFIG VARIABLE
	-----------------------------------------------------------------------
	audit                                         [ CONFIG_AUDIT ...      ]
	semundo                                       [ CONFIG_SYSVIPC        ]
	cpusets                                       [ CONFIG_CPUSETS        ]
	mempolicy                                     [ CONFIG_NUMA           ]
	trace irqflags                                [ CONFIG_TRACE_IRQFLAGS ]
	lockdep                                       [ CONFIG_LOCKDEP        ]
	keys (for processes -- not for thread groups) [ CONFIG_KEYS           ]
	process events connector                      [ CONFIG_PROC_EVENTS    ]

TODO:
	Mark the task watcher table ELF section read-only. I've tried to "fix"
	the .lds files to do this with no success. I'd really appreciate help
	from folks familiar with writing linker scripts.

	I'm working on three more patches that add support for creating a task
	watcher from within a module using an ELF section. They haven't recieved
	as much attention since I've been focusing on measuring the performance
	impact of these patches.

Changes:
since v2 ():
	Added ELF section annotations to the functions handling the events
	Added section annotation to the lookup table in kernel/task_watchers.c
	Added prefetch hints to the function pointer array walk
	Renamed the macros (better?)
	Retested the patches
	Reduced noise in test results (0.6 - 1%, 2+% previously)

With the last prefetch patch I was able to measure a performance increase in
the range of 0.4 to 2.8%. I sampled 100 times and took the mean for each patch.
Since the numbers seemed to be a source of confusion last time I've tried to
simplify them here:

Patch    Mean (forks/second)
0        6925.16 (baseline)
1        7170.81  task watchers
2        7100.34  audit
3        7114.47  semundo
4        7185.7   cpusets
5        7121.41  numa-mempolicy
6        7070.82  irqflags
7        7012.61  lockdep
8        7116.54  keys
9        7116.35  procevents
12       7109.52  prefetch
----------------------------------------------------
7109.52 - 6925.16 = +184 forks/second (+2.6%)

So the patch series now actually improves performance a little.

All the numbers from the tests are available if anyone wishes to analyze them
independently.

Please consider for inclusion in -mm.

Cheers,
	-Matt Helsley

             reply	other threads:[~2006-12-15  0:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-15  0:07 Matt Helsley [this message]
2006-12-15  0:07 ` Task watchers v2 Matt Helsley
2006-12-15  8:34   ` Christoph Hellwig
2006-12-15 22:17     ` Matt Helsley
2006-12-15 23:13     ` Matt Helsley
2006-12-18  5:44   ` Zhang, Yanmin
2006-12-18 13:18     ` Matt Helsley
2006-12-19  5:41       ` Paul Jackson
2006-12-19 12:05         ` Matt Helsley
2006-12-19 12:26           ` Paul Jackson
2006-12-15  0:07 ` Register audit task watcher Matt Helsley
2006-12-15  0:07 ` Register semundo " Matt Helsley
2006-12-15  0:07 ` Register cpuset " Matt Helsley
2006-12-15  0:07 ` Register NUMA mempolicy " Matt Helsley
2006-12-15  0:08 ` Register IRQ flag tracing " Matt Helsley
2006-12-15  0:08 ` Register lockdep " Matt Helsley
2006-12-15  0:08 ` Register process keyrings " Matt Helsley
2006-12-15  0:08 ` Register process events connector Matt Helsley
2006-12-15  0:08 ` Prefetch hint Matt Helsley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061215000754.764718000@us.ibm.com \
    --to=matthltc@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=hch@lst.de \
    --cc=jes@sgi.com \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pj@sgi.com \
    --cc=sgrubb@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox