From: rwhron@earthlink.net
To: andrea@suse.de
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.19pre9aa2
Date: Tue, 4 Jun 2002 08:44:01 -0400 [thread overview]
Message-ID: <20020604124401.GA13540@rushmore> (raw)
>> More benchmarks on quad Xeon at:
>> http://home.earthlink.net/~rwhron/kernel/bigbox.html
> Just a note, watch the "File & VM system latencies in microseconds"
> lmbench results, the creat become significantly slower, I'm wondering if
> that's due the removal of the negative dcache after unlink. I think it's
> still a global optimization (infact I think some of the dbench records
> are also thanks to maximzing the useful cache information by dropping
> immediatly negative dentries after unlink), but I wonder if the
> benchmark is done in a way that generate false positives. To avoid false
> positives and to really benchmark the whole "creat" path (that includes
> in its non-cached form also a lookup in the lowlevel fs) lmbench should
> rmdir; mkdir the directory where it wants to make the later creats
> (rmdir/mkdir cycle will drop negative dentries in all 2.[245] kernels
> too). Otherwise at the moment I'm unsure what made creat slower between
> pre8aa3 and pre9aa2, could it be a fake result of the benchmark?
I'll send you the 25 samples each of pre9aa2 and pre8aa3 off list.
All of the non-averaged lmbench results are currently at:
http://home.earthlink.net/~rwhron/kernel/lmball.txt
Some lmbench tests vary a lot. The 0k and 10k creat tests were
pretty consistent for these two kernels.
Other consistent tests that showed notable improvement were context
switching at 8p/16K, 8p/64K, and 16p/16K. The 16p/64K context switch
latency became inconsistent and higher on pre9aa2.
fork latency was consistent and improved by 10%.
> The pipe bandwith reported
> by lmbench in pre9aa2 is also very impressive, that's Mike's patch and I
> think it's also a very worthwhile optimizations since many tasks really
> uses pipes to passthrough big loads of data.
Yeah, that is impressive.
Glancing through the original lmbench logfiles, there are some results
that aren't in any report. creat 1k and 4k, and select on various
numbers of regular and tcp file descripters.
--
Randy Hron
next reply other threads:[~2002-06-04 12:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-04 12:44 rwhron [this message]
2002-06-04 13:01 ` 2.4.19pre9aa2 Andrea Arcangeli
-- strict thread matches above, loose matches on Subject: below --
2002-06-03 12:15 2.4.19pre9aa2 rwhron
2002-06-03 23:59 ` 2.4.19pre9aa2 Andrea Arcangeli
2002-05-31 5:18 2.4.19pre9aa2 Andrea Arcangeli
2002-05-31 13:13 ` 2.4.19pre9aa2 Andrey Nekrasov
2002-05-31 18:40 ` 2.4.19pre9aa2 Andrea Arcangeli
2002-05-31 19:55 ` 2.4.19pre9aa2 Andrew Morton
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=20020604124401.GA13540@rushmore \
--to=rwhron@earthlink.net \
--cc=andrea@suse.de \
--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