From: Sven-Thorsten Dietrich <thebigcorporation@gmail.com>
To: jordan johnston <triplesquarednine@gmail.com>
Cc: Mike Galbraith <efault@gmx.de>,
Xianghua Xiao <xiaoxianghua@gmail.com>,
"Walzer, Frank" <f-walzer@ti.com>,
"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>
Subject: Re: 2.6.35 RT support roadmap
Date: Thu, 12 Aug 2010 23:05:36 -0700 [thread overview]
Message-ID: <1281679536.7356.8.camel@baracus> (raw)
In-Reply-To: <AANLkTikoUbL4Q8PNia38AByEfTY56Bqr5uVnyyNxvS1W@mail.gmail.com>
On Thu, 2010-08-12 at 23:17 -0400, jordan johnston wrote:
> > Google did Android and even Palm woke up (just long enough to watch its own
> > demise).
> >
> > The rest is history.
> >
> > Except of course putting the RT Kernel in Android.
>
> As i understand it, many Android users are using the BFS patchset, and
> have been for a while. BFS pretty much does what "the end result of
> using the rt-patches" accomplish, minus rtirq, spin-locks, etc. You
> will get the desired
> responsiveness that using RT would give you.
>
I assume that it might well depend to some extent on whether I am
pumping market data feeds into a processing model using 512 CPUs or
playing a game on my Nexus-1, but I won't disagree agree with you on the
importance of task-appropriate efficient scheduling, appropriate
workload partitioning, and all that jazz.
> Im pretty sure that is why Zen-kernel has a git repository "very
> specifically" for android (BFS is the default kernel setting). I'm
> sure there are other goodies for android in there too.
>
> www.zen-kernel.org
>
> I don't know much about the Android repo's state (as it's fairly new).
> but worth a
> look for your "rt-usage" (ie. performance/responsiveness) for android.
> As i do not own an Android, i have not tested it, but i have talked
> with people who do..
>
> I'm waiting to see what 2.6.35 holds for RT.... but personally i am
> using BFS and 2.6.34 with a lot of performance tuning (a good deal of
> time spent analyzing/tuning) and i am yielding better results not
> using the upstream rt-patches.
> we will see what happens in 2.6.35/36....
>
Sounds good. I know there has been some extensive discussion about the
interpretation and applicability of the various scheduler performance
metrics, including special examination of BFS vs. CFS - and I definitely
think that has been hashed out in gore and detail already.
But if you have some pretty plots that characterize performance for your
platform, vs. Preempt-RT, I am always interested in looking at pictures
and numbers about what's happening on the other side of the fence.
Cheers,
Sven
> just my 2 cents :)
>
> cheers
>
> jordan
next prev parent reply other threads:[~2010-08-13 6:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-10 7:43 2.6.35 RT support roadmap Walzer, Frank
2010-08-12 14:38 ` Xianghua Xiao
2010-08-12 18:38 ` Mike Galbraith
2010-08-12 20:11 ` Sven-Thorsten Dietrich
2010-08-13 3:17 ` jordan johnston
2010-08-13 6:05 ` Sven-Thorsten Dietrich [this message]
2010-08-13 9:32 ` jordan johnston
2010-08-13 6:14 ` Mike Galbraith
2010-08-13 10:51 ` Walzer, Frank
2010-08-17 17:00 ` Clark Williams
2010-08-19 16:09 ` Sven-Thorsten Dietrich
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=1281679536.7356.8.camel@baracus \
--to=thebigcorporation@gmail.com \
--cc=efault@gmx.de \
--cc=f-walzer@ti.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=triplesquarednine@gmail.com \
--cc=xiaoxianghua@gmail.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.