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

Thu Jun 11 00:52:02 PDT 2015

Hi Vincent,

> 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.

I’ve switch my build to use 3.19.5-yocto-standard by adding a preferred_version to my local.conf. This has changed the behaviour:

1) At startup XOrg is still using a lot of memory (%VSZ goes above 88%);
2) The application works much better, but still has a few minor stutters every now and then;
3) XOrg memory usage (%VSZ) cycles between about 25% and 88%;
4) After a while (does not appear to be deterministic) the XOrg memory usage drops to and stays at a %VSZ of 4%;
5) At this point the application works as it did under daisy.

> 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)

I will have a go at down-versioning these to see if that makes any difference. I doubt GStreamer is the issue as I was already using 1.4.5 under daisy.

Thanks for the pointers :-)

> 
> ... 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!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20150611/8bdceb81/attachment.pgp>