Hi,
I just got a chance to run both L4Android and Android-x86 on an Asus EEE PC to measure their performance. In short, it seems to me that mag is causing some problem.
I ran the Android web browser, and measured the page load latency to measure the performance of both system.
I tried to keep the configuration of both side the same. For example, both system only use VESA, and they share the same userspace binaries.
L4Android did well in some cases, however, I saw more than 2x slow down from L4Android (notably http://www.android.com)
I suspect that this comes from mag -- I noticed that the graphics performance of L4Android is not great, for example, even boot animation lags on L4Android.
I suspect it'll take some time to fix, so is there a way to disable mag and let l4linux takes care of the frame buffer directly?
Thanks.
~Haohui
Hi,
On Fri Jul 06, 2012 at 17:07:24 -0500, Haohui Mai wrote:
I just got a chance to run both L4Android and Android-x86 on an Asus EEE PC to measure their performance. In short, it seems to me that mag is causing some problem.
I ran the Android web browser, and measured the page load latency to measure the performance of both system.
I tried to keep the configuration of both side the same. For example, both system only use VESA, and they share the same userspace binaries.
L4Android did well in some cases, however, I saw more than 2x slow down from L4Android (notably http://www.android.com)
I suspect that this comes from mag -- I noticed that the graphics performance of L4Android is not great, for example, even boot animation lags on L4Android.
I suspect it'll take some time to fix, so is there a way to disable mag and let l4linux takes care of the frame buffer directly?
Just give the fb cap, that is given to mag, directly to L4Linux. Additionally you need to configure L4Linux to provide the input device you need and adapt the io config accordingly so L4Linux can access those input devices.
Adam
Hi,
Getting rid of mag does improve the performance. I want to push it even further -- can I get rid of fb-drv completely to let L4Linux access the hardware directly?
I played around the configuration file a little bit but I had no luck.
~Haohui
On Mon, Jul 9, 2012 at 4:04 AM, Adam Lackorzynski adam@os.inf.tu-dresden.de wrote:
Hi,
On Fri Jul 06, 2012 at 17:07:24 -0500, Haohui Mai wrote:
I just got a chance to run both L4Android and Android-x86 on an Asus EEE PC to measure their performance. In short, it seems to me that mag is causing some problem.
I ran the Android web browser, and measured the page load latency to measure the performance of both system.
I tried to keep the configuration of both side the same. For example, both system only use VESA, and they share the same userspace binaries.
L4Android did well in some cases, however, I saw more than 2x slow down from L4Android (notably http://www.android.com)
I suspect that this comes from mag -- I noticed that the graphics performance of L4Android is not great, for example, even boot animation lags on L4Android.
I suspect it'll take some time to fix, so is there a way to disable mag and let l4linux takes care of the frame buffer directly?
Just give the fb cap, that is given to mag, directly to L4Linux. Additionally you need to configure L4Linux to provide the input device you need and adapt the io config accordingly so L4Linux can access those input devices.
Adam
Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hi,
On Mon Jul 09, 2012 at 15:49:35 -0500, Mai, Haohui wrote:
Getting rid of mag does improve the performance. I want to push it even further -- can I get rid of fb-drv completely to let L4Linux access the hardware directly?
fb-drv is a passive component doing nothing (except possible paging) after startup so that won't do any difference itself. The alternative here would probably be to not do any VESA/fbmem and let a graphics driver inside L4Linux completely manage the graphics card. Hopefully works as with any other PCI device.
Adam
Hi,
This is an important problem to solve. I'm seeing 60x slow down on the graphics component of L4Android right now because of this frame buffer issue.
I'm using an Eee PC which has an i945 chip. I tweaked my configuration a little bit but I still had no luck.
There're two possible bugs(?) here:
(1) The driver got confused because l4pci changes the func field of the pci table. The func field in PCI table is to describe whether there's another device attached to the slot. Here is code in Linux kernel causing problem:
gmch_device = pci_get_device(PCI_VENDOR_ID_INTEL, device, NULL); if (gmch_device && PCI_FUNC(gmch_device->devfn) != 0) { gmch_device = pci_get_device(PCI_VENDOR_ID_INTEL, device, gmch_device); }
On my machine, L4PCI reports the func field of my card (gmch_device in the code) as 1, which makes it find the "next" display card (i.e., executing the if branch). Therefore it cannot find the device.
I worked around it by disabling the if statement, and the kernel can detect the card and map in mmio memory.
(2) L4Linux is unable to execute "wbinvd" instruction. wbvind is a privileged instruction to write back all caches and invalidate them. The driver is executing this instruction at ring 3 -- thus generating a #GP fault.
This is more troublesome and I don't really have a good idea of how to fix it. I appreciate if you can tell me the quickest way of fixing it.
~Haohui
On Mon, Jul 9, 2012 at 4:54 PM, Adam Lackorzynski adam@os.inf.tu-dresden.de wrote:
Hi,
On Mon Jul 09, 2012 at 15:49:35 -0500, Mai, Haohui wrote:
Getting rid of mag does improve the performance. I want to push it even further -- can I get rid of fb-drv completely to let L4Linux access the hardware directly?
fb-drv is a passive component doing nothing (except possible paging) after startup so that won't do any difference itself. The alternative here would probably be to not do any VESA/fbmem and let a graphics driver inside L4Linux completely manage the graphics card. Hopefully works as with any other PCI device.
Adam
Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hi,
On Wed Jul 11, 2012 at 15:20:33 -0500, Mai, Haohui wrote:
This is an important problem to solve. I'm seeing 60x slow down on the graphics component of L4Android right now because of this frame buffer issue.
This is software rendering versus something with hardware support.
I'm using an Eee PC which has an i945 chip. I tweaked my configuration a little bit but I still had no luck.
There're two possible bugs(?) here:
(1) The driver got confused because l4pci changes the func field of the pci table. The func field in PCI table is to describe whether there's another device attached to the slot. Here is code in Linux kernel causing problem:
gmch_device = pci_get_device(PCI_VENDOR_ID_INTEL, device, NULL); if (gmch_device && PCI_FUNC(gmch_device->devfn) != 0) { gmch_device = pci_get_device(PCI_VENDOR_ID_INTEL, device, gmch_device); }On my machine, L4PCI reports the func field of my card (gmch_device in the code) as 1, which makes it find the "next" display card (i.e., executing the if branch). Therefore it cannot find the device.
I worked around it by disabling the if statement, and the kernel can detect the card and map in mmio memory.
Are you using PCI_bus_ident() instead of PCI_bus() in your vbus config?
(2) L4Linux is unable to execute "wbinvd" instruction. wbvind is a privileged instruction to write back all caches and invalidate them. The driver is executing this instruction at ring 3 -- thus generating a #GP fault.
This is more troublesome and I don't really have a good idea of how to fix it. I appreciate if you can tell me the quickest way of fixing it.
Looking at this a bit... this is just done for initializing the ringbuffer which lives in non-caches memory already. It does not seem to be used during runtime. There's also no comment why such a complete global flush is required at all. Maybe to flush something else? Hmm. My suggestion would thus just be to comment that out and see if it works without.
Adam
Hi,
Thanks. Please see the inlined response.
On Wed, Jul 11, 2012 at 5:08 PM, Adam Lackorzynski adam@os.inf.tu-dresden.de wrote:
Hi,
On Wed Jul 11, 2012 at 15:20:33 -0500, Mai, Haohui wrote:
This is an important problem to solve. I'm seeing 60x slow down on the graphics component of L4Android right now because of this frame buffer issue.
This is software rendering versus something with hardware support.
Exactly. That's the reason why I really want to enable it. :-)
I'm using an Eee PC which has an i945 chip. I tweaked my configuration a little bit but I still had no luck.
There're two possible bugs(?) here:
(1) The driver got confused because l4pci changes the func field of the pci table. The func field in PCI table is to describe whether there's another device attached to the slot. Here is code in Linux kernel causing problem:
gmch_device = pci_get_device(PCI_VENDOR_ID_INTEL, device, NULL); if (gmch_device && PCI_FUNC(gmch_device->devfn) != 0) { gmch_device = pci_get_device(PCI_VENDOR_ID_INTEL, device, gmch_device); }On my machine, L4PCI reports the func field of my card (gmch_device in the code) as 1, which makes it find the "next" display card (i.e., executing the if branch). Therefore it cannot find the device.
I worked around it by disabling the if statement, and the kernel can detect the card and map in mmio memory.
Are you using PCI_bus_ident() instead of PCI_bus() in your vbus config?
I have PCI/CC_03 mapped in two caps, one in PCI_bus_ident() and one in PCI_bus(). I could try it out.
(2) L4Linux is unable to execute "wbinvd" instruction. wbvind is a privileged instruction to write back all caches and invalidate them. The driver is executing this instruction at ring 3 -- thus generating a #GP fault.
This is more troublesome and I don't really have a good idea of how to fix it. I appreciate if you can tell me the quickest way of fixing it.
Looking at this a bit... this is just done for initializing the ringbuffer which lives in non-caches memory already. It does not seem to be used during runtime. There's also no comment why such a complete global flush is required at all. Maybe to flush something else? Hmm. My suggestion would thus just be to comment that out and see if it works without.
There're a couple places that uses this instruction. I did try to disable the wbinvd instruction entirely but it didn't work. So what do you think to take to implement it in L4Linux?
Adam
Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hi,
On Wed Jul 11, 2012 at 21:42:59 -0500, Mai, Haohui wrote:
I'm using an Eee PC which has an i945 chip. I tweaked my configuration a little bit but I still had no luck.
There're two possible bugs(?) here:
(1) The driver got confused because l4pci changes the func field of the pci table. The func field in PCI table is to describe whether there's another device attached to the slot. Here is code in Linux kernel causing problem:
gmch_device = pci_get_device(PCI_VENDOR_ID_INTEL, device, NULL); if (gmch_device && PCI_FUNC(gmch_device->devfn) != 0) { gmch_device = pci_get_device(PCI_VENDOR_ID_INTEL, device, gmch_device); }On my machine, L4PCI reports the func field of my card (gmch_device in the code) as 1, which makes it find the "next" display card (i.e., executing the if branch). Therefore it cannot find the device.
I worked around it by disabling the if statement, and the kernel can detect the card and map in mmio memory.
Are you using PCI_bus_ident() instead of PCI_bus() in your vbus config?
I have PCI/CC_03 mapped in two caps, one in PCI_bus_ident() and one in PCI_bus(). I could try it out.
Just use one.
(2) L4Linux is unable to execute "wbinvd" instruction. wbvind is a privileged instruction to write back all caches and invalidate them. The driver is executing this instruction at ring 3 -- thus generating a #GP fault.
This is more troublesome and I don't really have a good idea of how to fix it. I appreciate if you can tell me the quickest way of fixing it.
Looking at this a bit... this is just done for initializing the ringbuffer which lives in non-caches memory already. It does not seem to be used during runtime. There's also no comment why such a complete global flush is required at all. Maybe to flush something else? Hmm. My suggestion would thus just be to comment that out and see if it works without.
There're a couple places that uses this instruction. I did try to disable the wbinvd instruction entirely but it didn't work. So what do you think to take to implement it in L4Linux?
We're talking about flush_cache() in i810_main.h? Anyway there seems to be some consensus that an interface for that might be acceptable.
Adam
l4-hackers@os.inf.tu-dresden.de
-
Adam Lackorzynski -
Haohui Mai -
Mai, Haohui