All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Max Müller" <mxmr@gmx.net>
To: Clark Williams <williams@redhat.com>
Cc: linux-rt-users@vger.kernel.org
Subject: Re: Tweak Latency on Intel ATOM
Date: Tue, 16 Feb 2010 07:50:02 +0100	[thread overview]
Message-ID: <4B7A401A.70902@gmx.net> (raw)
In-Reply-To: <20100215083847.1a4a7ef0@torg>

Clark Williams schrieb:
> On Mon, 15 Feb 2010 10:32:54 +0100
> Max Müller <mxmr@gmx.net> wrote:
>  
>   
>>> I'd say you're doing pretty good keeping under 50us. You might want to
>>> try it under a heavier load than the shell script you've been running.
>>> If you don't want to fool with rteval, try kicking off a kernel compile
>>> in another window like this:
>>>
>>> $ while true; do make -j4 clean bzImage modules; done
>>>
>>> and then run cyclictest. A kernel compile with parallel jobs (-j) is a
>>> good overall load of computation and I/O.
>>>
>>>   
>>>       
>> I tested now like you told me with irqbalance and cpuspeed services 
>> disabled. I hope i made the right for disabling irqbalance, i used the 
>> kernel parameter acpi_no_irqbalance. Is this correct? Unfortunately the 
>> results were nearly equal as before.
>>     
>
> I don't think you're going to get much better results on the Atom. I
> have an MSI Nettop box with the dual-core version and I saw about the
> same results as you.
>
> What sort of scheduling deadlines are you trying to meet? 
>
> Clark
>   
Shorter it is better it would be :-)
I can also live with this results, but i wanted to make sure to get the 
best out of this hardware.

Are you running both cores on the MSI box (maybe also with 
hyperthreading enabled) with this results?

In the meantime i thought also if the SMI (system management mode) could 
have a bad influence. I wrote a little userspace  programm which 
disables global SMI bit of the ICH7 southbridge. But also no better 
results.
After that i was told (thanks to Luis Claudio!) to check latency with 
the kernel module hwlat_detector. The results of this module was 0. I 
interpreted this that there is no SMI that causes the latency on my ATOM 
system.

Regards,
Max


--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-02-16  6:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-09  7:41 Tweak Latency on Intel ATOM Max Miller
2010-02-10 22:38 ` Clark Williams
2010-02-11  7:54   ` Max Müller
2010-02-11 15:34     ` Clark Williams
2010-02-15  9:32       ` Max Müller
2010-02-15 14:38         ` Clark Williams
2010-02-16  6:50           ` Max Müller [this message]
2010-02-16 12:18             ` Luis Claudio R. Goncalves
2010-02-17  6:26               ` Max Müller
2010-02-12 20:54     ` mapping of PCI memory to user space not working with uio.c ? Armin Steinhoff

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=4B7A401A.70902@gmx.net \
    --to=mxmr@gmx.net \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=williams@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.