public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Fireball Freddy <fireballfreddy@yahoo.com>
To: linux-kernel@vger.kernel.org
Subject: Comparing buffer cache algorithms on 2.2.17.  Suggestions?
Date: Sat, 17 Feb 2001 14:15:40 -0800 (PST)	[thread overview]
Message-ID: <20010217221540.23972.qmail@web2104.mail.yahoo.com> (raw)

Howdy,

  Trying to implement some different buffer caching
algorithms in Linux.  This is just for comparison
purposes for a thesis, not suggesting any problem with
the current scheme.  Here is what I'm attempting:

  o Eliminate BUF_CLEAN, BUF_DIRTY, and BUF_LOCKED
lists in favor of a single BUF_LRU list.  This because
I don't see the point of maintaining three lists...
the only time I need to find all the dirty blocks is
on a sync of some sort.  I don't mind if the sync
takes a while longer if the normal operating condition
is faster.

  Once I have the cache working on a single list
(assuming I can!) I plan on using an I/O generator to
get some repeatable traces so I can compare the
following:

  o LRU vs SLRU with static region percentages vs SLRU
with dynamic region percentages
  o Periodic flushing of dirty blocks enabled vs
disabled
  o Write-through caching vs write-back caching vs
adaptive (switching between wt and wb based on recent
activity) vs my own method (write to disk on first
write, only to buffer after that, write to disk again
when block is flushed, if dirty)
  o Of course, I'll also do a run with the default
Linux 2.2.17 to see how it compares with the others

  It looks like the ext2 fs is going to complicate
this somewhat, as it sets blocks dirty and/or writes
them itself sometimes.  Not sure how I'm going to get
around this... will probably ignore it for now.

  I'd appreciate any advice on this undertaking. 
Specifically, how many things (tools, etc) is this
going to break, warnings about common pitfalls, and
other suggestions.  I would like to have started this
on 2.4, but I wanted to work on a release that had
been out for a bit, so I'd know that any problems were
caused by *me* and not just kernel bugs.  :)

  Also, are there any specific people to whom I should
direct memory management questions?  I've had some in
the past few months but haven't been able to get
answers.  Or should I post them to this list (I assume
not).  Finally, I have noticed references to a
kernelnewbies chat room.  I prefer newsgroups to
chat... is there a good mailing list devoted to kernel
newbies?

  Thanks to everyone for your hard work, and apologies
for adding one more e-mail to the pile.

    Andy Cottrell

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

             reply	other threads:[~2001-02-17 22:16 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-17 22:15 Fireball Freddy [this message]
2001-02-19 19:10 ` Comparing buffer cache algorithms on 2.2.17. Suggestions? Stephen Tweedie

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=20010217221540.23972.qmail@web2104.mail.yahoo.com \
    --to=fireballfreddy@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    /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