public inbox for linux-rt-users@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Stanislav Meduna <stano@meduna.org>
Cc: linux-rt-users@vger.kernel.org
Subject: Re: loading pages to memory causes high latency
Date: Sat, 27 Oct 2012 11:56:03 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.02.1210271147280.2756@ionos> (raw)
In-Reply-To: <508BA412.5020708@meduna.org>

On Sat, 27 Oct 2012, Stanislav Meduna wrote:
> On 27.10.2012 10:38, Thomas Gleixner wrote:
> 
> > There is not much we can do about that unless we want to do a major
> > surgery on that pata driver code.
> > 
> > So either you disable the throttler or you reconfigure the pata irq
> > thread to SCHED_OTHER, which will slow it down a bit, but avoids the
> > hogging of the machine with a RT task going wild.
> 
> Thank you for the analysis. Yep I'll reconfigure it to SCHED_OTHER -
> file access is a totally low-prio thing in my application and I was more
> afraid of a possibility where someone fetching logfiles or something
> like that will bring the application to the knees.
> 
> BTW what granularity does the throttler have? I cannot live with
> 50 ms lag once in a second, but in my case I can well live with
> 5 ms lag once in 100 ms (even if that means that the throttler
> would be activated more often).

The granularity is microseconds. 

sched_rt_period  defaults to 1000000	== 1.00s
sched_rt_runtime defaults to  950000	== 0.95s

The mechanics of the throttler is that it gives SCHED_OTHER a chance
to run for sched_rt_period - sched_rt_runtime (default 0.05s == 50ms)
if RT tasks hogged the cpu for more than sched_rt_runtime in a row.

This is a safety belt, so you have a chance to kill your RT task which
got lost in a while(1) loop :)

> Right now I have
> 
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ=y
> CONFIG_HZ=1000
> CONFIG_SCHED_HRTICK=y
> 
> and lacking better choices my clock source is TSC. I admit that
> I do not know what precisely each setting does - the NO_HZ combined
> with HZ=1000 looks a bit weird ;)

HZ is the scheduler tick frequency. That's used for timeslicing
SCHED_OTHER tasks.

NO_HZ is only affecting idle. When the machine goes idle and the next
timer expires AFTER the next scheduler tick, then the scheduler tick
is stopped and the timer device is armed to the timer expiry. That's a
power saving feature as it allows the CPU to stay in deeper
powerstates for a longer time, instead of waking up with HZ frequency
just to see that there is nothing to do, which is silly as we know
that right when we go idle :)

Thanks,

	tglx

      reply	other threads:[~2012-10-27  9:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-26 18:00 loading pages to memory causes high latency Stanislav Meduna
2012-10-26 21:04 ` Thomas Gleixner
2012-10-27  8:38   ` Thomas Gleixner
2012-10-27  9:06     ` Stanislav Meduna
2012-10-27  9:56       ` Thomas Gleixner [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=alpine.LFD.2.02.1210271147280.2756@ionos \
    --to=tglx@linutronix.de \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=stano@meduna.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