All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kok, Auke" <auke-jan.h.kok@intel.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: powertop ml <power@bughost.org>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Ingo Molnar <mingo@elte.hu>,
	srostedt@redhat.com
Subject: [ANNOUNCE] sreadahead-1.0
Date: Tue, 27 Jan 2009 12:06:59 -0800	[thread overview]
Message-ID: <497F6963.6060701@intel.com> (raw)


All,

we're happy to announce a major rewrite of sreadahead, and the release of version
1.0. This is a significant improvement in the way sreadahead works:

* sreadahead now will work on any filesystem;

  Sreadahead used to use an ioctl to retreive inserted timestamps from ext3
  inodes. This patch is now replaced with a generic open() syscall tracer,
  which will work on all filesystems.

* pack file generation is now integrated entirely in a single binary, and
  automatically done if the pack file is missing;

  Sreadahead is now a single-binary two-purpose program that either reads in
  the content needed, or generates this content. This reduces the chance that
  sreadahead is called incorrectly, but also makes installation a lot easier.
  Sreadahead can now be added to the boot system by inserting a single line
  in a startup script.

* pack file generation is now significantly faster than the old method;

  Sreadahead now uses a kernel tracer which provides with a sort-by-use list of
  all files opened. This removes the need for a special script to discover
  which files were opened at boot. This list is sorted and filtered in C
  code inside sreadahead which proves much faster. The old method took
  multiple seconds. New method sorts/filters 10k+ open trace calls in 0.16s
  on a regular desktop.

* sreadahead now accounts for kernel read_ahead_kb, reducing data read
  at boot time;

  While sreadahead reads "used" data into memory, the kernel reports more
  memory in use than actually used due to the in-kernel readahead function.
  In order to read significantly less data, sreadahead temporarily reduces
  this amount, saving significant amount of total IO time. This saves as
  much as 8 out of 64Mb on a regular fedora core installation.


Sreadahead still depends on a kernel patch (posted in a followup). This patch
implements a global kernel tracer for sys_open() syscalls. The choice was made to
use this method since userland tracing is slow, cumbersome (have to attach to
every process running), and hard to implement for system-wide tracing (we don't
care about which process is doing something). A kernel tracer is extremely
efficient and added bonus is that we can leave the trace in memory until we
actually need to process it.

sreadahead-1.0 can be downloaded from it's google code project page here:

  http://sreadahead.googlecode.com/


Regards,

Auke

                 reply	other threads:[~2009-01-27 20:07 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=497F6963.6060701@intel.com \
    --to=auke-jan.h.kok@intel.com \
    --cc=arjan@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=power@bughost.org \
    --cc=srostedt@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.