public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Davide Libenzi <davidel@xmailserver.org>,
	Ulrich Drepper <drepper@redhat.com>,
	Jeff Garzik <jeff@garzik.org>, Zach Brown <zach.brown@oracle.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Arjan van de Ven <arjan@infradead.org>,
	Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@zip.com.au>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	"David S. Miller" <davem@davemloft.net>,
	Suparna Bhattacharya <suparna@in.ibm.com>,
	Jens Axboe <jens.axboe@oracle.com>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Syslets, Threadlets, generic AIO support, v6
Date: Thu, 31 May 2007 12:50:48 +0200	[thread overview]
Message-ID: <20070531105048.GA19796@elte.hu> (raw)
In-Reply-To: <20070531124129.31c14ddd.dada1@cosmosbay.com>


* Eric Dumazet <dada1@cosmosbay.com> wrote:

> I tried your bench and found two problems :
> - You scan half of the bitmap
[...]
> Try to close not a 'middle fd', but a really low one (10 for example), 
> and latencie is doubled.

that was intentional. I really didnt want to fabricate a worst-case 
result but something more representative: in real apps the bitmap isnt 
fully filled all the time and most of the find-bit sequences are short. 
Hence the two fds and one of them goes from the middle of the range.

> - You incorrectlty divide best_delta and worst_delta by LOOPS (5)

ah, indeed, that's a bug - victim of a last minute edit :) Since the 
divident is constant it doesnt really matter to the validity of the 
relative nature of the slowdown (which is what i was intested in), but 
you are right - i have fixed the download and have redone the numbers. 
Here are the correct results from my box:

 # ./fd-scale-bench 1000000 0
 checking the cache-hot performance of open()-ing 1000000 fds.
 num_fds: 1, best cost: 6.00 us, worst cost: 8.00 us
 num_fds: 2, best cost: 6.00 us, worst cost: 7.00 us
 ...
 num_fds: 31586, best cost: 7.00 us, worst cost: 8.00 us
 num_fds: 39483, best cost: 8.00 us, worst cost: 8.00 us
 num_fds: 49354, best cost: 7.00 us, worst cost: 9.00 us
 num_fds: 61693, best cost: 8.00 us, worst cost: 10.00 us
 num_fds: 77117, best cost: 8.00 us, worst cost: 13.00 us
 num_fds: 96397, best cost: 9.00 us, worst cost: 11.00 us
 num_fds: 120497, best cost: 10.00 us, worst cost: 14.00 us
 num_fds: 150622, best cost: 11.00 us, worst cost: 13.00 us
 num_fds: 188278, best cost: 12.00 us, worst cost: 15.00 us
 num_fds: 235348, best cost: 14.00 us, worst cost: 20.00 us
 num_fds: 294186, best cost: 16.00 us, worst cost: 22.00 us
 num_fds: 367733, best cost: 19.00 us, worst cost: 35.00 us
 num_fds: 459667, best cost: 22.00 us, worst cost: 37.00 us
 num_fds: 574584, best cost: 26.00 us, worst cost: 40.00 us
 num_fds: 718231, best cost: 31.00 us, worst cost: 62.00 us
 num_fds: 897789, best cost: 37.00 us, worst cost: 54.00 us
 num_fds: 1000000, best cost: 41.00 us, worst cost: 59.00 us

and cache-cold:

 # ./fd-scale-bench 1000000 1
 checking the cache-cold performance of open()-ing 1000000 fds.
 num_fds: 1, best cost: 24.00 us, worst cost: 32.00 us
 ...
 num_fds: 49354, best cost: 26.00 us, worst cost: 28.00 us
 num_fds: 61693, best cost: 25.00 us, worst cost: 30.00 us
 num_fds: 77117, best cost: 27.00 us, worst cost: 30.00 us
 num_fds: 96397, best cost: 27.00 us, worst cost: 31.00 us
 num_fds: 120497, best cost: 31.00 us, worst cost: 43.00 us
 num_fds: 150622, best cost: 31.00 us, worst cost: 34.00 us
 num_fds: 188278, best cost: 33.00 us, worst cost: 36.00 us
 num_fds: 235348, best cost: 35.00 us, worst cost: 42.00 us
 num_fds: 294186, best cost: 36.00 us, worst cost: 41.00 us
 num_fds: 367733, best cost: 40.00 us, worst cost: 43.00 us
 num_fds: 459667, best cost: 44.00 us, worst cost: 46.00 us
 num_fds: 574584, best cost: 48.00 us, worst cost: 65.00 us
 num_fds: 718231, best cost: 54.00 us, worst cost: 59.00 us
 num_fds: 897789, best cost: 60.00 us, worst cost: 62.00 us
 num_fds: 1000000, best cost: 65.00 us, worst cost: 68.00 us

> with a corrected bench; cache-cold numbers are > 100 us on this Intel 
> Pentium-M
> 
> num_fds: 1000000, best cost: 120.00 us, worst cost: 131.00 us
> 
> On an Opteron x86_64 machine, results are better :)
> 
> num_fds: 1000000, best cost: 28.00 us, worst cost: 106.00 us

yeah. I quoted the full range because i was really more interested of 
our current 'limit' range (which is somewhere between 50K and 100K open 
fds) where the scanning cost becomes directly measurable, and the nature 
of slowdown.

	Ingo

  reply	other threads:[~2007-05-31 10:51 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-29 21:27 Syslets, Threadlets, generic AIO support, v6 Zach Brown
2007-05-29 21:49 ` Linus Torvalds
2007-05-29 22:49   ` Zach Brown
2007-05-29 22:16 ` Jeff Garzik
2007-05-29 23:09   ` Zach Brown
2007-05-29 23:20     ` Ulrich Drepper
2007-05-30  1:11       ` Dave Jones
2007-05-30 17:08         ` Zach Brown
2007-05-30  7:26     ` Ingo Molnar
2007-05-30  7:20   ` Ingo Molnar
2007-05-30  7:31     ` Ulrich Drepper
2007-05-30  8:42       ` Ingo Molnar
2007-05-30  8:51         ` Evgeniy Polyakov
2007-05-30  9:05           ` Ingo Molnar
2007-05-30 15:16         ` Linus Torvalds
2007-05-30 15:39         ` Ulrich Drepper
2007-05-30 19:40         ` Davide Libenzi
2007-05-30 19:55           ` Ulrich Drepper
2007-05-30 20:00           ` Linus Torvalds
2007-05-30 20:21             ` Davide Libenzi
2007-05-30 20:31             ` Eric Dumazet
2007-05-30 20:44               ` Linus Torvalds
2007-05-30 21:53                 ` Eric Dumazet
2007-05-30 21:31               ` Davide Libenzi
2007-05-30 21:16             ` Ulrich Drepper
2007-05-30 21:27               ` Linus Torvalds
2007-05-30 21:47                 ` Ulrich Drepper
2007-05-30 22:06                   ` Davide Libenzi
2007-05-30 21:48                 ` Davide Libenzi
2007-05-30 22:01                   ` Linus Torvalds
2007-05-31  6:13                     ` Ingo Molnar
2007-05-31  7:35                       ` Eric Dumazet
2007-05-31  9:26                         ` Ingo Molnar
2007-05-31  9:02                       ` Ingo Molnar
2007-05-31 10:41                         ` Eric Dumazet
2007-05-31 10:50                           ` Ingo Molnar [this message]
2007-05-31  9:32                       ` Ingo Molnar
2007-05-31  9:34                         ` Jens Axboe
2007-05-30 22:09                   ` Eric Dumazet
2007-05-30 21:51                 ` David M. Lloyd
2007-05-30 22:24                 ` William Lee Irwin III
2007-05-30 21:38               ` Jeremy Fitzhardinge
2007-05-30 21:39               ` Davide Libenzi
2007-05-30 21:36             ` Jeremy Fitzhardinge
2007-05-30 21:44               ` Linus Torvalds
2007-05-30 21:48                 ` Linus Torvalds
2007-05-30 21:54                   ` Jeremy Fitzhardinge
2007-05-30 22:27             ` Matt Mackall
2007-05-30 22:38               ` William Lee Irwin III
2007-05-30  8:32     ` Evgeniy Polyakov
2007-05-30  8:54       ` Ingo Molnar
2007-05-30  9:30         ` Evgeniy Polyakov
2007-05-30  9:28     ` Jeff Garzik
2007-05-30 13:02       ` Ingo Molnar
2007-05-30 13:20         ` Ingo Molnar
2007-05-30 15:31       ` Linus Torvalds
2007-05-30 16:09         ` Ingo Molnar
2007-05-30 17:57           ` Jens Axboe
2007-05-30 19:05           ` Mark Lord
2007-05-30 19:10             ` Jens Axboe
2007-05-30 19:15             ` Linus Torvalds
2007-05-30 19:32               ` Jens Axboe
2007-05-30 20:07               ` Eric Dumazet
2007-05-30 20:31                 ` Linus Torvalds
2007-05-30 20:46                   ` Eric Dumazet
2007-05-30 19:52           ` Davide Libenzi
2007-05-30  7:40 ` Jens Axboe
2007-05-30 16:55   ` Zach Brown
2007-05-30 17:33     ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2007-05-31  8:15 Albert Cahalan
2007-05-31  9:50 ` Ingo Molnar

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=20070531105048.GA19796@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@zip.com.au \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --cc=davidel@xmailserver.org \
    --cc=drepper@redhat.com \
    --cc=hch@infradead.org \
    --cc=jeff@garzik.org \
    --cc=jens.axboe@oracle.com \
    --cc=johnpol@2ka.mipt.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suparna@in.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=zach.brown@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox