public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: George Anzinger <george@mvista.com>
To: tglx@linutronix.de
Cc: Darren Hart <dvhltc@us.ibm.com>,
	Geoff Levand <geoffrey.levand@am.sony.com>,
	"Theodore Ts'o" <tytso@mit.edu>,
	"'high-res-timers-discourse@lists.sourceforge.net'" 
	<high-res-timers-discourse@lists.sourceforge.net>,
	"lkml," <linux-kernel@vger.kernel.org>,
	dino@us.ibm.com, Paul McKenney <paulmck@us.ibm.com>,
	"Sarma, Dipankar" <dipankar@in.ibm.com>
Subject: Re: HRT on opteron / rt14 on opteron
Date: Tue, 27 Sep 2005 14:44:46 -0700	[thread overview]
Message-ID: <4339BD4E.3060401@mvista.com> (raw)
In-Reply-To: <1127684460.15115.116.camel@tglx.tec.linutronix.de>

Thomas Gleixner wrote:
> On Fri, 2005-09-23 at 16:04 -0700, Darren Hart wrote:
> 
>>I am trying to run all the tests in the above tarball on a 2.6.13 kernel with 
>>ktimers+tod+hrt + a hrt compatibility patch which uses the normal clocks when a 
>>_HR clock is requested since ktimers treats them the same.  I remember there 
>>used to be a run_tests script or something when this was a kernel patch, but I 
> 
> 
> do_test
~
>># ./timerlimit
>>7168: timer id = 7167
>>timer_create: Resource temporarily unavailable
>>
>>Is that a reasonable number of successfully created clocks?
> 
> 
> Depends on the number of timers available on your system. But sounds
> reasonable.

Actually is limited by the maximum number of signal control block.  This 
is, I think, an RLIMIT and can be changed.  Currently it is set to 1024 
by default.
> 
> I have no idea about the plots. George ?

The plot code was done to get a handle on the performance of the timer 
list code.  The plot should be showing the list overhead as a function 
of the number of timers.  To get reasonable inteaction you may need to 
adjust the RLIMIT up so you can get 3000 to 6000 timers.

This code was done when we were using the hashed timer list and showed 
very good performance up to and above 3000 timers.  The hashed timer 
list did NOT have a cascade issue and I still think it may be a 
reasonable replacement for the cascade timer list.  It also had the nice 
ability to change the hash bucket size at configure time to improve 
performance as needed.
> 

-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/

      parent reply	other threads:[~2005-09-27 21:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <432F21D1.90209@us.ibm.com>
     [not found] ` <432F5A44.9010208@am.sony.com>
2005-09-23 23:04   ` HRT on opteron / rt14 on opteron Darren Hart
2005-09-25 21:41     ` Thomas Gleixner
2005-09-26 16:52       ` Geoff Levand
2005-09-27 21:44       ` George Anzinger [this message]

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=4339BD4E.3060401@mvista.com \
    --to=george@mvista.com \
    --cc=dino@us.ibm.com \
    --cc=dipankar@in.ibm.com \
    --cc=dvhltc@us.ibm.com \
    --cc=geoffrey.levand@am.sony.com \
    --cc=high-res-timers-discourse@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@us.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=tytso@mit.edu \
    /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