[yocto] [meta-intel] "Crazy" Xorg memory usage after upgrading from Daisy to Fido

Cheah, Vincent Beng Keat vincent.beng.keat.cheah at intel.com
Tue Nov 24 16:20:56 PST 2015


Hi Chris, 

Sorry for the lateness in reply, was too busy with other things. Good to hear that.

Xorg.conf is basically to force load particular intended driver (in this case X11 SNA Driver). This is something that that we do not get when we bit-bake for a yocto image; mainly because users from different companies/purpose may want to use customized their own xorg.conf based on their needs.  You can check for which X11 driver that got loaded into your Yocto system simply by checking that on the /var/log/Xorg.0.log

In our lab, in order to make sure that our drivers are loaded correctly, we normally, build i915 as a module and add a xorg.conf files (containing some of the stuff below). 
Generally, in most of the case, we will get this loaded correctly (without Xorg.conf) but there do are times when we do not get the desired driver loaded. 

Section "Device"
        Identifier      "Card0"
        Driver          "intel"
        BusID           "0:2:0"
        Screen          0
EndSection

... Vincent 


-----Original Message-----
From: Chris Tapp [mailto:opensource at keylevel.com] 
Sent: Wednesday, November 25, 2015 7:44 AM
To: Cheah, Vincent Beng Keat <vincent.beng.keat.cheah at intel.com>
Cc: Yocto Project <yocto at yoctoproject.org>; Chang, Rebecca Swee Fun <rebecca.swee.fun.chang at intel.com>; Paul Eggleton <paul.eggleton at linux.intel.com>; meta-intel at yoctoproject.org
Subject: Re: [yocto] [meta-intel] "Crazy" Xorg memory usage after upgrading from Daisy to Fido

Hi Vincent,

I may have made some progress. The undesirable memory usage within Xorg isn’t there if I create an xorg.conf file containing:

Section “Device”
  Identifier “Intel Video”
  Driver “intel”
  Option “TearFree” “true"
EndSection

So it looks as if I need to enable “TearFree”. I didn’t need to add this for the 2.99.910 version of xf86-video-intel included with ‘daisy’.

Chris

> On 23 Nov 2015, at 23:48, Chris Tapp <opensource at keylevel.com> wrote:
> 
> Hi Vincent,
> 
> I’ve finally got back to being able to investigate this further.
> 
> I’ve now moved on to “jethro” and I’m seeing exactly the same behaviour. I’ve tried with kernel versions 3.14.39, 3.19.5 and 4.1.8.
> 
>> On 10 Jun 2015, at 03:50, Cheah, Vincent Beng Keat <vincent.beng.keat.cheah at intel.com> wrote:
>> 
>> Hi Chris,
>> 
>> I don’t have any idea with regard to the issue that you are getting below. All the work that we are doing here so far is on CHV (yocto-kernel-3.19.5 standard/base branch).
>> 
>> From your statement below, it looks to me that you are upgrading meta-intel from Daisy to Fido branch which are using yocto-kernel-3.14 (meta-intel/isg/valleyisland BSP). I'm not sure if you are able to reproduce this with yocto-kernel-3.19.5 (standard/base branch) from the meta-intel common directory. Also, comparing Daisy branch against Fido, it seems like there are lot of changes in the user-space stacks, which I'm not sure could cause the issue below.
>> 
>> 
>> Daisy 1.6.2
>> 	Kernel 3.4, 3.10, 3.14 (Supportable common base)
>> 	Xorg-server 1.15
>> 	Wayland/Weston 1.4.0
>> 	Xf86-video-intel 2.99.910
>> 	Libdrm 2.4.52
>> 	MESA 9.2.5
>> 	Cairo 1.12.16
>> 	libVA 1.3.1 (from meta-intel)
>> 	Intel-VA-driver 1.3.2 (from meta-intel)
>> 	GStreamer 1.2.3
>> 	GStreamer-VAAPI 0.5.8 (from meta-intel)
>> 
>> 
>> Dizzy 1.7.1
>> 	Kernel 3.10, 3.14, 3.17 (Supportable common base)
>> 	Xorg-server 1.15.1
>> 	Wayland/Weston 1.5.0
>> 	Xf86-video-intel 2.99.912
>> 	Libdrm 2.4.54
>> 	MESA 10.1.3
>> 	Cairo 1.12.16
>> 	libVA 1.3.1 (from meta-intel)
>> 	Intel-VA-driver 1.3.2 (from meta-intel)
>> 	GStreamer 1.4.1
>> 	GStreamer-VAAPI 0.5.8 (from meta-intel)
>> 
>> 
>> Fido 1.8
>> 	Kernel 3.14, 3.19 (supportable comon base)
>> 	Xorg-server 1.16.3
>> 	Wayland/weston 1.6.0
>> 	Xf86-video-intel 2.99.917
>> 	Libdrm 2.4.59
>> 	Mesa 10.4.4
>> 	Cairo 1.12.18
>> 	LibVA 1.5.0 (from meta-intel)
>> 	Intel-VA-driver 1.5.0 (from meta-intel)
>> 	Gstreamer 1.4.5
>> 	Gstreamer-vaapi 0.5.10 (from meta-intel)
>> 
>> 
>> ... Vincent
>> 
>> -----Original Message-----
>> From: Chang, Rebecca Swee Fun
>> Sent: Wednesday, June 10, 2015 9:08 AM
>> To: Cheah, Vincent Beng Keat
>> Cc: meta-intel at yoctoproject.org; Chris Tapp; Yocto Project; Wold, Saul; 'Paul Eggleton'
>> Subject: RE: [meta-intel] "Crazy" Xorg memory usage after upgrading 
>> from Daisy to Fido
>> 
>> Hi Vincent,
>> 
>> Can you help to comment on this issue mentioned by Chris?
>> Thanks.
>> 
>> Regards,
>> Rebecca
>> 
>>> -----Original Message-----
>>> From: Paul Eggleton [mailto:paul.eggleton at linux.intel.com]
>>> Sent: 09 June, 2015 12:15 AM
>>> To: Chang, Rebecca Swee Fun
>>> Cc: meta-intel at yoctoproject.org; Chris Tapp; Yocto Project; Wold, 
>>> Saul
>>> Subject: Re: [meta-intel] "Crazy" Xorg memory usage after upgrading 
>>> from Daisy to Fido
>>> 
>>> Rebecca, is this something you or one of your colleagues would be 
>>> able to help with?
>>> 
>>> Thanks,
>>> Paul
>>> 
>>> On Friday 05 June 2015 08:29:00 Chris Tapp wrote:
>>>> I’ve got an application that I’ve had running nicely under Daisy 
>>>> for some time. As Daisy is now a bit old, I decided to move the 
>>>> application to
>>> Fido.
>>>> I’m using the meta-intel/isg/valleyisland BSP and also switched to 
>>>> using its Fido branch.
>>>> 
>>>> The move only required a few minor changes and allowed me to drop a 
>>>> Daisy “updates” layer that I had been using for things like gstreamer-1.0.
>>>> 
>>>> However, there is one behaviour which is killing me - I keep 
>>>> getting oom-killer events!
>>>> 
>>>> The application is basically an OpenGL-ES 2.0 application that 
>>>> renders various bits of text, images and streams captured from a 
>>>> gstreamer pipeline at 60 Hz to a 1080 screen.
>>>> 
>>>> Under Daisy this generally took just under 50% CPU and used a 
>>>> modest percentage of the 4 GB system memory - i.e. no where near 
>>>> running out and usage was just about static.
>>>> 
>>>> Under Fido the CPU usage is about the same and the memory used by 
>>>> the application itself looks reasonable when compared to Daisy (and 
>>>> usage is static). However, the memory used by XOrg is far from 
>>>> constant or stable - it basically has a VSZ value cycling from 
>>>> about 630m to 2989m with the cycle period being in the order of 5 
>>>> to 10 seconds. Peaks in XOrg memory usage coincide with stutters in 
>>>> video playback within my app (audio is unaffected).
>>>> 
>>>> Monitoring /proc/meminfo when this is going on shows that “Shmem”
>>>> usage is following the same pattern as the memory used by XOrg (i.e.
>>>> Shmem usage is high at the same time). If the values are plotted on 
>>>> a graph they appear to show that Shmem usage grows linearly and 
>>>> then falls rapidly when nearly all the free memory has been 
>>>> exhausted, perhaps in response to a delayed garbage collection run.
>>>> 
>>>> Does anyone have any ideas as to what I should be looking at to 
>>>> work out what’s going on?
>>>> 
>>>> Are there any significant changes between XOrg under Daisy and Fido 
>>>> that could be causing this?
>>>> 
>>>> Could this be related to the meta-intel video drivers?
>>>> 
>>>> Any feedback / comments would be really appreciated.
>>>> 
>>>> Thanks :-)
>>>> 
>>>> --
>>>> 
>>>> Chris Tapp
>>>> opensource at keylevel.com
>>>> www.keylevel.com
>>>> 
>>>> ----
>>>> You can tell you're getting older when your car insurance gets real cheap!
>>> 
>>> --
>>> 
>>> Paul Eggleton
>>> Intel Open Source Technology Centre
> 
> --
> 
> Chris Tapp
> opensource at keylevel.com
> www.keylevel.com
> 
> ----
> You can tell you're getting older when your car insurance gets real cheap!
> 
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

--

Chris Tapp
opensource at keylevel.com
www.keylevel.com

----
You can tell you're getting older when your car insurance gets real cheap!



More information about the yocto mailing list