24 Oct
2010
24 Oct
'10
6:42 p.m.
I just got Meego 1.1 SDK up and running on my Fedora12 desktop, courtesy of
"yum install kqemu qemu-kvm libvirt-client libvirt"
&&
http://wiki.meego.com/SDK/Docs/1.1/Getting_started_with_the_MeeGo_SDK_for_L…
&&
http://www.exerciseforthereader.org/PCBSD/PCBSD8_under_qemu-kvm.html
(essential in the above is that RPMFusion "metapackage" kqemu will
install the appropriate kernel-dependent module, e.g.
kmod-kqemu-2.6.32.21-168.fc12.x86_64 from rpmfusion-free-updates )
So I can now from my 2.6.32.21-168.fc12.x86_64 desktop cut/paste
"root@meego-netbook-sdk:~# uname -a
Linux localhost.localdomain 2.6.35~rc6-134.1-qemu #1 SMP PREEMPT Thu
Jul 29 10:40:24 UTC 2010 i686 i686 i386 GNU/Linux"
from a gnome-terminal running in the kvm, even though there's a tiny
little netbook/handheld emulator running somewhere on my desktop too.
Not sure why I'd want to use it for devel/admin when I can run any X
app via:
ssh -f -Y root@localhost -p 6666 "exec dbus-launch gnome-terminal
&/dev/null </dev/null
I still have a little
http://people.redhat.com/berrange/olpc/sdk/network-bridge.html
to work through. However so far, it's outrageously easy in a modern
linux to setup and tear down other virtual OSes, and the performance
is surprisingly good, at least when emulating a 32 bit atom on a 64
bit phenom II :-)
I was surprised&happy to see "SMP PREEMPT" output from my virtual Meego
logs:
Oct 23 21:30:24 localhost klogd: [ 0.000000] Linux version
2.6.35~rc6-134.1-qemu (abuild@build16) (gcc version 4.5.0 20100414
(MeeGo 4.5.0-1) (GCC) ) #1 SMP PREEMPT Thu Jul 29 10:40:24 UTC 2010
Seems like all that's missing between this solution and my "meegolem"
hack of adding Fedora RPMFusion and PlanetCCRMA app/lib/devel
repositories to Meego is the "RT" from the CCRMA realtime kernel? Or
is Meego 1.1 already fully realtime capable and the message just omits
"RT" ?
What aspects of http://lwn.net/Articles/319544/ are in Meego 1.1?
Is this just a side-effect of modern linux kernels adopting the
preempt/rt patches:
http://events.linuxfoundation.org/2010/linuxcon-brasil/pt/gleixner ?
Does this mean, in the future, that separate realtime kernels as
provided for Fedora/Ubuntu distros will no longer be needed? And that
we'll be able to configure our systems for RT usage as needed?
Question: In a KVM/qemu environment, would I still be able to use all
the goodness the PREEMPT features of my virtual Meego 1.1 provide for
audio/media usage?
Next step -- try out "Meegolem" hack (
http://lalists.stanford.edu/lau/2010/09/0480.html
http://lalists.stanford.edu/lau/2010/09/0502.html ) on KVM'd Meego 1.1
and see how well "virtualized" media applications work. And figure out
http://libvirt.org/formatdomain.html#elementsSound to see if there's a
way of allocating a specific soundcard for use by
jack-audio-connection-kit (although I did get netjack running
previously in 1.0, so could use jackd on the "host" OS and netjack on
the virtualized one with some SSH tunneling).
However the netjack solution doesn't really scratch the realtime itch,
and SSH tunnelling across localhost isn't exactly the definition of
performance. The question is, would it work to have the the OS with
preempt features running in a KVM; using jackd in that OS to gain
realtime and exclusive access to specific media hardware. Would that
provide realtime performance for just the apps needing it, running in
the virtualized realtime kernel, or would that be a recipe for
disaster?
-- Niels
http://nielsmayer.com
PS: Assuming there was a way for me to grant exclusive access to a
particular soundcard from a given KVM OS, would I be able to
experiment with writing/changing an ALSA device driver for a
particular device within the "experimental OS" running in KVM, while
using all my other devices/desktop as normal, without fear of
crashes/hangs/etc? Is this a sensible development strategy?
24 Oct
24 Oct
11:03 p.m.
New subject: Gone virtually Meego 1.1 in Fedora -- lots of questions....
On Sun, Oct 24, 2010 at 12:42 PM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
Is this just a side-effect of modern linux kernels
adopting the
preempt/rt patches:
http://events.linuxfoundation.org/2010/linuxcon-brasil/pt/gleixner ?
Does this mean, in the future, that separate realtime kernels as
provided for Fedora/Ubuntu distros will no longer be needed? And that
we'll be able to configure our systems for RT usage as needed?
the mainstream kernel has merged *parts* of the RT patch. it does not
have all of it, and the last time i heard gleixner talk about it (last
fall, in portland, OR at the linux plumbers conf) he felt that it
unlikely that it would ever all be merged.
configuring your system for RT usage has ABSOLUTELY ZERO to do with
the presence or absence of the RT patch. RT scheduling, mlock and
other features used by RT applications are all available and usable on
all modern linux kernels. the RT patch just makes them work better, on
some machines, some of the time.
25 Oct
25 Oct
8:16 a.m.
New subject: Gone virtually Meego 1.1 in Fedora -- lots of questions....
On Sun, Oct 24, 2010 at 2:03 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
the mainstream kernel has merged *parts* of the RT
patch. it does not
have all of it, and the last time i heard gleixner talk about it (last
fall, in portland, OR at the linux plumbers conf) he felt that it
unlikely that it would ever all be merged.
Paul -- thanks for the clarifications. Hopefully somebody from the
Meego community will be able to respond further to the specific RT
capabilities (or lack thereof) in Meego 1.1.
configuring your system for RT usage has ABSOLUTELY
ZERO to do with
the presence or absence of the RT patch. RT scheduling, mlock and
other features used by RT applications are all available and usable on
all modern linux kernels. the RT patch just makes them work better, on
some machines, some of the time.
True -- I use them currently with a stock fedora kernel (which is
where I run my KVMs out of). This functions adequately for most
low-channel purposes using tools like jack, ardour and qtractor -- as
long as I'm not running certain other applications concurrently (such
as a web browser doing heavy javascript processing, like browsing
gmail).
However, "rtirq" is one such configuration change which does have
something to do with the presence of the RT patch, and appears to be
in inequality with "absolutely zero." especially the all-capitalized
variety. :-)
...
Regarding virtualization and multimedia devices access, Fedora 14
claims "Easier virtualization for end users. From the creators of KVM
comes Spice (Simple Protocol for Independent Computing Environments).
This framework allows end-users to enjoy the features they enjoy, such
as accelerated 2D graphics, encryption, and audio playing and
recording, all while working in a virtualized environment" ...
///// ///// ///// ///// /////
The other big news is Spice, the Simple Protocol for Independent
Computing Environments. Spice is part of Red Hat's Qumranet
acquisition[2], which also brought the now standard KVM virtualization
to both RHEL and Fedora.
The goal of the Spice project is to improve remote access to QEMU
virtual machines. For those running Windows clients in a virtual
machine Spice includes a few Windows helpers right out of the box
including a video driver, an agent for performing operations inside
the guest system and virtio serial drivers for talking to the agent.
Although Spice has been available in the Yum repos since Fedora 12,
the new tools make getting Spice up and running much easier and should
be good news for those with multiple virtual machines to manage.
The cloud gets an update, too.
Fedora 14 will mark the first time that Fedora will concurrently
release all its usual spins and a new Amazon EC2 image. That's great
news for those using Amazon's cloud hosting to run Fedora machines."
↑ http://lists.fedoraproject.org/pipermail/marketing/2010-September/013438.ht…
↑ http://www.redhat.com/about/news/prarchive/2009/spice-os.html
↑ http://www.channelregister.co.uk/2010/09/29/fedora_14_beta_review/
///// ///// ///// ///// /////
-- Niels
http://nielsmayer.com
PS: Potentially answering some of my previous questions:
app-emulation/qemu-kvm-spice:alsa,
app-emulation/qemu-kvm-spice:pulseaudio,
app-emulation/qemu-kvm-spice:esd ... (which are not in F12... yet
another reason to upgrade to F14 around the end of November...).
2:47 p.m.
New subject: Gone virtually Meego 1.1 in Fedora -- lots of questions....
On Mon, Oct 25, 2010 at 2:16 AM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
However, "rtirq" is one such configuration
change which does have
something to do with the presence of the RT patch, and appears to be
in inequality with "absolutely zero." especially the all-capitalized
variety. :-)
rtirq is specifically related to the way the RT patch creates
per-interrupt threads. it adjusts the priorities of those threads in
ways that appear to be helpful. its not directly related to RT
scheduling or applications, and on some systems its use is completely
unnecessary. on those where it is useful, its very useful.
5:23 p.m.
New subject: Gone virtually Meego 1.1 in Fedora -- lots of questions....
Hi Neils,
On Sun, Oct 24, 2010 at 11:42 AM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
I was surprised&happy to see "SMP
PREEMPT" output from my virtual Meego logs:
Oct 23 21:30:24 localhost klogd: [ 0.000000] Linux version
2.6.35~rc6-134.1-qemu (abuild@build16) (gcc version 4.5.0 20100414
(MeeGo 4.5.0-1) (GCC) ) #1 SMP PREEMPT Thu Jul 29 10:40:24 UTC 2010
Seems like all that's missing between this solution and my "meegolem"
hack of adding Fedora RPMFusion and PlanetCCRMA app/lib/devel
repositories to Meego is the "RT" from the CCRMA realtime kernel? Or
is Meego 1.1 already fully realtime capable and the message just omits
"RT" ?
MeeGo's kernel is not PREEMPT_RT.
For several good reasons, MeeGo needs a 2.6.35 kernel, and there
currently is no -rt patch for that kernel.
At the moment, pro audio performance on MeeGo is bad because of CPU
frequency scaling. However, if you disable it[1] I'm getting good RT
performance from MeeGo.
-gabriel
[1] One way is to recompile the kernel with some different config options.
4950
days inactive
4951
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Gabriel Beddingfield -
Niels Mayer -
Paul Davis