public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: Andrew Morton <andrewm@uow.edu.au>, Shawn Starr <Shawn.Starr@Home.net>
Cc: Shawn Starr <Shawn.Starr@Home.com>,
	Gregory Maxwell <greg@linuxpower.cx>,
	linux-kernel@vger.kernel.org
Subject: Re: Kernel 2.4.x and 2.4.1-preX - Higher latency then 2.2.xkernels?
Date: Sun, 28 Jan 2001 14:17:10 -0500	[thread overview]
Message-ID: <203550000.980709430@tiny> (raw)
In-Reply-To: <3A739205.7C71EF89@uow.edu.au>



On Sunday, January 28, 2001 02:29:09 PM +1100 Andrew Morton
<andrewm@uow.edu.au> wrote:

> Shawn Starr wrote:
>> 
>> Andrew, the patch HAS made a difference. For example, while untaring
>> glibc-2.2.1.tar.gz the system was not sluggish (mouse movements in X)
>> etc.
>> 
>> Seems to be a go for latency improvements on this system.
> 
> hmm..  OK, thanks.
> 
> Chris, this seems to be a worthwhile improvement to mainstream
> reiserfs, independent of the low-latency thing.   You can
> probably achieve 10 milliseconds with just a few lines of
> code - a subset of the patch which Shawn tested. (Unless you
> were planning on magical algorithmic improvements...).
> 
> I'm all set up to generate those few lines of code, so
> I'll propose a patch later this week.

Perfect, I was thinking exactly the same thing.  We have to be careful here
though, since the extra schedules will increase the chance the searching
has to be redone from scratch, which can have big performance ramifications.

I think your change to search_by_key will be the safest for performance
considerations, along with the change to prepare_for_delete_or_cut.  If
those won't be enough, we can attack reiserfs_get_block (who is probably
the biggest single offender without your patch).

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2001-01-28 19:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-20 19:50 Kernel 2.4.x and 2.4.1-preX - Higher latency then 2.2.x kernels? Shawn Starr
2001-01-20 19:59 ` Gregory Maxwell
2001-01-20 20:16   ` Shawn Starr
2001-01-21 18:09   ` Chris Mason
2001-01-21 23:25     ` Kernel 2.4.x and 2.4.1-preX - Higher latency then 2.2.xkernels? Shawn Starr
2001-01-27  8:08       ` Andrew Morton
2001-01-27  8:04         ` Shawn Starr
2001-01-28  2:55           ` Shawn Starr
2001-01-28  3:29             ` Andrew Morton
2001-01-28  3:59               ` Shawn Starr
2001-01-28 19:17               ` Chris Mason [this message]
2001-01-29  0:33                 ` Shawn Starr
2001-01-28 11:46             ` Andrew Morton
2001-01-28 21:53               ` Shawn Starr

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=203550000.980709430@tiny \
    --to=mason@suse.com \
    --cc=Shawn.Starr@Home.com \
    --cc=Shawn.Starr@Home.net \
    --cc=andrewm@uow.edu.au \
    --cc=greg@linuxpower.cx \
    --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