Right lib-imx/firmware-imx ... versions

Right lib-imx/firmware-imx ... versions

[Jens Rehsack]

Hi,

as mentioned in my very first post here, we're trying to get a board
running with yocto with a bsp for linux-imx-3.0.35_4.1.0 (bdde708).

As firmware-imx we have 3.0.35_4.0.0 (tried 3.10.17, too - without
difference).

When we run xmbc with lib-imx, gpu-viv-ib-mx6q, lib-vpu in daisy
versions (3.10.17), xbmc immediately crashes with a segfault in
gpu-viv-ib-mx6q (does someone wants the trace?). Using Dora versions
(3.10.9) we can at least start xbmc and can start one movie. When
we play a second movie, the system crashes with "dma physical memory
allocation error" (trace/console output wanted?).

The board manufacturer recommends we try the freescale libs (firmware,
lib-imx, gpu...) in precisely matching version (3.0.35_4.1.0), but none
of them seems to exist in meta-fsl-arm(-extra). That confuses me in the
way that I expect, the distributed versions are stable.

Though I don't have a concrete question beside "what library versions
are good for us?" - any hints, resources to study, ...?

Thank you very much.

Best regards
-- 
Jens Rehsack
rehsack@gmail.com

Re: Right lib-imx/firmware-imx ... versions

[Jens Rehsack]

Am 22.07.2014 um 07:24 schrieb Jens Rehsack <rehsack@gmail.com>:

> Hi,
> 
> as mentioned in my very first post here, we're trying to get a board
> running with yocto with a bsp for linux-imx-3.0.35_4.1.0 (bdde708).
> 
> As firmware-imx we have 3.0.35_4.0.0 (tried 3.10.17, too - without
> difference).
> 
> When we run xmbc with lib-imx, gpu-viv-ib-mx6q, lib-vpu in daisy
> versions (3.10.17), xbmc immediately crashes with a segfault in
> gpu-viv-ib-mx6q (does someone wants the trace?). Using Dora versions
> (3.10.9) we can at least start xbmc and can start one movie. When
> we play a second movie, the system crashes with "dma physical memory
> allocation error" (trace/console output wanted?).
> 
> The board manufacturer recommends we try the freescale libs (firmware,
> lib-imx, gpu...) in precisely matching version (3.0.35_4.1.0), but none
> of them seems to exist in meta-fsl-arm(-extra). That confuses me in the
> way that I expect, the distributed versions are stable.
> 
> Though I don't have a concrete question beside "what library versions
> are good for us?" - any hints, resources to study, ...?
> 
> Thank you very much.

Not even a hint? Is it so obvious and I'm to green to see it?

Cheers
-- 
Jens Rehsack
rehsack@gmail.com

Re: Right lib-imx/firmware-imx ... versions

[Daiane Angolini]

On Tue, Jul 22, 2014 at 2:24 AM, Jens Rehsack <rehsack@gmail.com> wrote:
> Hi,
>
> as mentioned in my very first post here, we're trying to get a board
> running with yocto with a bsp for linux-imx-3.0.35_4.1.0 (bdde708).
>
> As firmware-imx we have 3.0.35_4.0.0 (tried 3.10.17, too - without
> difference).

Long story short: Stick to one branch and use it, with the kernel
version and the imx-lib/gpu/imx-vpu/firmware version already there. It
was what we tested someway.

Long story long:

>
> When we run xmbc with lib-imx, gpu-viv-ib-mx6q, lib-vpu in daisy
> versions (3.10.17), xbmc immediately crashes with a segfault in
> gpu-viv-ib-mx6q (does someone wants the trace?). Using Dora versions
> (3.10.9) we can at least start xbmc and can start one movie. When
> we play a second movie, the system crashes with "dma physical memory
> allocation error" (trace/console output wanted?).

I don´t have previous success cases in running xbmc. I mean, I have
never (myself) tried it, but in other hand, I have never heard about
someone that had succeeded.

So, I don´t know if *any* combination works.

>
> The board manufacturer recommends we try the freescale libs (firmware,
> lib-imx, gpu...) in precisely matching version (3.0.35_4.1.0), but none
> of them seems to exist in meta-fsl-arm(-extra). That confuses me in the
> way that I expect, the distributed versions are stable.

When dealing with GPU, is important that the kernel GPU driver and the
GPU user-space package match.

When working with IPU for imx6. It does not matter what imx-lib you is
working with. ipu-lib is not used for imx6 since 3.0.15, or something
like that. So, for IPU, no user-space package needed.

When working with VPU, imx-vpu is needed, and imx-firmware is needed.
However, any should work, and what you miss from one to another is
only bugfixes. (of course, it´s may be a huge difference, however I
don´t see it causing a crash)


>
> Though I don't have a concrete question beside "what library versions
> are good for us?" - any hints, resources to study, ...?

So, the question "what library version are good for us" should be
answered by another question "do you need libraries?"

Or, let´s be more practical. Have you tested your GPU integration?
What is the GPU driver version in your kernel, and your GPU user-space
version?


Daiane

Re: Right lib-imx/firmware-imx ... versions

[Jens Rehsack]

Am 23.07.2014 um 16:19 schrieb Daiane Angolini <daiane.list@gmail.com>:

> On Tue, Jul 22, 2014 at 2:24 AM, Jens Rehsack <rehsack@gmail.com> wrote:
>> Hi,
>> 
>> as mentioned in my very first post here, we're trying to get a board
>> running with yocto with a bsp for linux-imx-3.0.35_4.1.0 (bdde708).
>> 
>> As firmware-imx we have 3.0.35_4.0.0 (tried 3.10.17, too - without
>> difference).
> 
> Long story short: Stick to one branch and use it, with the kernel
> version and the imx-lib/gpu/imx-vpu/firmware version already there. It
> was what we tested someway.

But there is no Yocto support for imx-lib-3.0.35_4.1.0, neither that
imx-vpu nor gpu-viv-lib-mxq version. Only 3.10.9 and 3.10.17 is included
(daisy has only 3.10.17).

> Long story long:
> 
>> When we run xmbc with lib-imx, gpu-viv-ib-mx6q, lib-vpu in daisy
>> versions (3.10.17), xbmc immediately crashes with a segfault in
>> gpu-viv-ib-mx6q (does someone wants the trace?). Using Dora versions
>> (3.10.9) we can at least start xbmc and can start one movie. When
>> we play a second movie, the system crashes with "dma physical memory
>> allocation error" (trace/console output wanted?).
> 
> I don´t have previous success cases in running xbmc. I mean, I have
> never (myself) tried it, but in other hand, I have never heard about
> someone that had succeeded.

http://stephan-rafin.net/blog/ or more concrete: http://stephan-rafin.net/blog/2014/01/29/yet-another-yocto-image/

But as far as I see from his recipes, he's using mx6d.

> So, I don´t know if *any* combination works.
> 
>> The board manufacturer recommends we try the freescale libs (firmware,
>> lib-imx, gpu...) in precisely matching version (3.0.35_4.1.0), but none
>> of them seems to exist in meta-fsl-arm(-extra). That confuses me in the
>> way that I expect, the distributed versions are stable.
> 
> When dealing with GPU, is important that the kernel GPU driver and the
> GPU user-space package match.

As said, I have linux-imx-3.0.35_4.1.0 at revision bdde708 with patches
https://github.com/rehsack/meta-jens/tree/master/recipes-kernel/linux/linux-curie-3.0.35

Doesn't look to me as if any modifies GPU kernel driver ...

> When working with IPU for imx6. It does not matter what imx-lib you is
> working with. ipu-lib is not used for imx6 since 3.0.15, or something
> like that. So, for IPU, no user-space package needed.

k

> When working with VPU, imx-vpu is needed, and imx-firmware is needed.
> However, any should work, and what you miss from one to another is
> only bugfixes. (of course, it´s may be a huge difference, however I
> don´t see it causing a crash)

The crash I see with xbmc and 3.10.9 drivers (firmware-imx-3.0.35_4.0.0+
imx-lib-, imx-vpu- & gpu-viv-lib-mx6q-3.10.9_1.0.0) is nearly byte-identical
to https://community.freescale.com/thread/304414 ...

However, with gpu-viv-lib-mx6q (other versions doesn't seem to matter in
any way), it immediately crashes 

#0  0x2be582b0 in gcoHAL_QueryChipCount (Hal=Hal@entry=0x0,
   Count=Count@entry=0x1c3b65c) at gc_hal_user_query.c:1726
#1  0x2b275244 in veglGetThreadData () at gc_egl.c:137
#2  0x2b26e210 in eglfGetDisplay (display_id=0x1c2b568) at gc_egl_init.c:464
#3  eglGetDisplay (DisplayID=0x1c2b568) at gc_egl_init.c:565
#4  0x00880fac in CEGLWrapper::InitDisplay (this=0x1c16c40,
   display=display@entry=0x1a64e50) at EGLWrapper.cpp:206

which points to gpu-viv-lib-mx6q ...

>> Though I don't have a concrete question beside "what library versions
>> are good for us?" - any hints, resources to study, ...?
> 
> So, the question "what library version are good for us" should be
> answered by another question "do you need libraries?"

From available xbmc recipes I think so - but maybe the imx port isn't
the right way. OTOH, looks as if wolfgar did a good job there, at least
for wandboard, uitite & co.

> Or, let´s be more practical. Have you tested your GPU integration?
> What is the GPU driver version in your kernel, and your GPU user-space
> version?

Nope, how can I do that (fsl for dummies - I'm happy controlling Yocto
meanwhile). Just bitbake imx-test or something more?

Thanks in advance.

Best regards
-- 
Jens Rehsack
rehsack@gmail.com

Re: Right lib-imx/firmware-imx ... versions

[xxiao8]

On 07/23/2014 09:51 AM, Jens Rehsack wrote:
> When working with IPU for imx6. It does not matter what imx-lib you is
> >working with. ipu-lib is not used for imx6 since 3.0.15, or something
> >like that. So, for IPU, no user-space package needed.

I am using ipu-lib in 3.0.15, what do you mean "ipu-lib is not used for 
imx6 since 3.0.15"? is it replaced by something else?

Thanks,
Xiao

Re: Right lib-imx/firmware-imx ... versions

[Daiane Angolini]

On Wed, Jul 23, 2014 at 12:14 PM, xxiao8 <xxiao8@fosiao.com> wrote:
>
> On 07/23/2014 09:51 AM, Jens Rehsack wrote:
>>
>> When working with IPU for imx6. It does not matter what imx-lib you is
>> >working with. ipu-lib is not used for imx6 since 3.0.15, or something
>> >like that. So, for IPU, no user-space package needed.
>
>
> I am using ipu-lib in 3.0.15, what do you mean "ipu-lib is not used for imx6
> since 3.0.15"? is it replaced by something else?

I mean that, at some point in time *which I don´t remember exactly*
the ipu-lib (the same used in imx53) was integrated in the ipu kernel
driver.


I don´t know if this is exactly at 3.0.15, or any point before that,
I´m sorry for the noise.


Daiane

Re: Right lib-imx/firmware-imx ... versions

[Daiane Angolini]

On Wed, Jul 23, 2014 at 11:51 AM, Jens Rehsack <rehsack@gmail.com> wrote:
>
> Am 23.07.2014 um 16:19 schrieb Daiane Angolini <daiane.list@gmail.com>:
>
>> On Tue, Jul 22, 2014 at 2:24 AM, Jens Rehsack <rehsack@gmail.com> wrote:
>>> Hi,
>>>
>>> as mentioned in my very first post here, we're trying to get a board
>>> running with yocto with a bsp for linux-imx-3.0.35_4.1.0 (bdde708).
>>>
>>> As firmware-imx we have 3.0.35_4.0.0 (tried 3.10.17, too - without
>>> difference).
>>
>> Long story short: Stick to one branch and use it, with the kernel
>> version and the imx-lib/gpu/imx-vpu/firmware version already there. It
>> was what we tested someway.
>
> But there is no Yocto support for imx-lib-3.0.35_4.1.0, neither that
> imx-vpu nor gpu-viv-lib-mxq version. Only 3.10.9 and 3.10.17 is included
> (daisy has only 3.10.17).


I don´t remember exactly which version was used in each branch. Sorry.
I can only say to you that using the branch as-is, was enough to my
uses.


>> Or, let´s be more practical. Have you tested your GPU integration?
>> What is the GPU driver version in your kernel, and your GPU user-space
>> version?
>
> Nope, how can I do that (fsl for dummies - I'm happy controlling Yocto
> meanwhile). Just bitbake imx-test or something more?


For this kernel:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-kernel/linux/linux-imx_3.0.35.bb?h=dora

Use this GPU user space
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/gpu-viv-bin-mx6q?h=dora

hfp or sfp....

The Original 3.0.35-4.0.1 is not compatible with
gpu-viv-bin-mx6q_3.10.9-1.0.0, that´s why there is a patch to upgrade
3.0.35 to GPU driver p13

However, it does not mean that this combination is free of bug.

And remember it´s only a hint. As you said at first, community does
not support linux-imx-3.0.35 any more.


Daiane

Re: Right lib-imx/firmware-imx ... versions

[Jens Rehsack]

Am 23.07.2014 um 17:45 schrieb Daiane Angolini <daiane.list@gmail.com>:

> On Wed, Jul 23, 2014 at 11:51 AM, Jens Rehsack <rehsack@gmail.com> wrote:
>> 
>> Am 23.07.2014 um 16:19 schrieb Daiane Angolini <daiane.list@gmail.com>:
>> 
>>> On Tue, Jul 22, 2014 at 2:24 AM, Jens Rehsack <rehsack@gmail.com> wrote:
>>>> Hi,
>>>> 
>>>> as mentioned in my very first post here, we're trying to get a board
>>>> running with yocto with a bsp for linux-imx-3.0.35_4.1.0 (bdde708).
>>>> 
>>>> As firmware-imx we have 3.0.35_4.0.0 (tried 3.10.17, too - without
>>>> difference).
>>> 
>>> Long story short: Stick to one branch and use it, with the kernel
>>> version and the imx-lib/gpu/imx-vpu/firmware version already there. It
>>> was what we tested someway.
>> 
>> But there is no Yocto support for imx-lib-3.0.35_4.1.0, neither that
>> imx-vpu nor gpu-viv-lib-mxq version. Only 3.10.9 and 3.10.17 is included
>> (daisy has only 3.10.17).
> 
> I don´t remember exactly which version was used in each branch. Sorry.
> I can only say to you that using the branch as-is, was enough to my
> uses.
> 
> 
>>> Or, let´s be more practical. Have you tested your GPU integration?
>>> What is the GPU driver version in your kernel, and your GPU user-space
>>> version?
>> 
>> Nope, how can I do that (fsl for dummies - I'm happy controlling Yocto
>> meanwhile). Just bitbake imx-test or something more?
> 
> 
> For this kernel:
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-kernel/linux/linux-imx_3.0.35.bb?h=dora
> 
> Use this GPU user space
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/gpu-viv-bin-mx6q?h=dora
> 
> hfp or sfp....
> 
> The Original 3.0.35-4.0.1 is not compatible with
> gpu-viv-bin-mx6q_3.10.9-1.0.0, that´s why there is a patch to upgrade
> 3.0.35 to GPU driver p13

I didn't see that patch, digging for unless ... bsp porting isn't an option.

> However, it does not mean that this combination is free of bug.
> 
> And remember it´s only a hint. As you said at first, community does
> not support linux-imx-3.0.35 any more.

I took a look into differences between imx_3.10.17_1.0.0_ga and
wandboard_imx_3.10.17_1.0.0_ga to get a picture what I have to hack to
port the bsp from 3.0.35 to 3.10.17 - but I miss the place where
previously platform initialization happened (arch/arm/mach-mx6/board-mx6q_sabresd.*)

Is there a suitable guide explaining bsp porting from imx_3.0.35_4.1.0 to
imx_3.10.17_1.0.0?

Cheers
-- 
Jens Rehsack
rehsack@gmail.com

Re: Right lib-imx/firmware-imx ... versions

[Jens Rehsack]

Am 23.07.2014 um 19:31 schrieb Jens Rehsack <rehsack@gmail.com>:

It's a bit ago ... but for the records (and pay back a little bit)

> Am 23.07.2014 um 17:45 schrieb Daiane Angolini <daiane.list@gmail.com>:
> 
>> On Wed, Jul 23, 2014 at 11:51 AM, Jens Rehsack <rehsack@gmail.com> wrote:
>>> 
>>> Am 23.07.2014 um 16:19 schrieb Daiane Angolini <daiane.list@gmail.com>:
>>> 
>>>> On Tue, Jul 22, 2014 at 2:24 AM, Jens Rehsack <rehsack@gmail.com> wrote:
>>>>> Hi,
>>>>> 
>>>>> as mentioned in my very first post here, we're trying to get a board
>>>>> running with yocto with a bsp for linux-imx-3.0.35_4.1.0 (bdde708).
>>>>> 
>>>>> As firmware-imx we have 3.0.35_4.0.0 (tried 3.10.17, too - without
>>>>> difference).
>>>> 
>>>> Long story short: Stick to one branch and use it, with the kernel
>>>> version and the imx-lib/gpu/imx-vpu/firmware version already there. It
>>>> was what we tested someway.
>>> 
>>> But there is no Yocto support for imx-lib-3.0.35_4.1.0, neither that
>>> imx-vpu nor gpu-viv-lib-mxq version. Only 3.10.9 and 3.10.17 is included
>>> (daisy has only 3.10.17).
>> 
>> I don´t remember exactly which version was used in each branch. Sorry.
>> I can only say to you that using the branch as-is, was enough to my
>> uses.
>> 
>> 
>>>> Or, let´s be more practical. Have you tested your GPU integration?
>>>> What is the GPU driver version in your kernel, and your GPU user-space
>>>> version?
>>> 
>>> Nope, how can I do that (fsl for dummies - I'm happy controlling Yocto
>>> meanwhile). Just bitbake imx-test or something more?
>> 
>> 
>> For this kernel:
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-kernel/linux/linux-imx_3.0.35.bb?h=dora
>> 
>> Use this GPU user space
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-arm/tree/recipes-graphics/gpu-viv-bin-mx6q?h=dora
>> 
>> hfp or sfp....
>> 
>> The Original 3.0.35-4.0.1 is not compatible with
>> gpu-viv-bin-mx6q_3.10.9-1.0.0, that´s why there is a patch to upgrade
>> 3.0.35 to GPU driver p13
> 
> I didn't see that patch, digging for unless ... bsp porting isn't an option.

Found such a patch in old wandboard kernels - I reused some more of the patches
there ...

>> However, it does not mean that this combination is free of bug.
>> 
>> And remember it´s only a hint. As you said at first, community does
>> not support linux-imx-3.0.35 any more.
> 
> I took a look into differences between imx_3.10.17_1.0.0_ga and
> wandboard_imx_3.10.17_1.0.0_ga to get a picture what I have to hack to
> port the bsp from 3.0.35 to 3.10.17 - but I miss the place where
> previously platform initialization happened (arch/arm/mach-mx6/board-mx6q_sabresd.*)
> 
> Is there a suitable guide explaining bsp porting from imx_3.0.35_4.1.0 to
> imx_3.10.17_1.0.0?

Daiane, because you also was involved into https://community.freescale.com/thread/304414:

I digged a lot deeper, tried https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233
and debugged and proved more there ...
I also tried to get a picture of vmm by browsing "Understanding The Linux Virtual Memory Manager" by Mel Gorman.

My result: When no swap is configured (and the box has none - because of 1GB RAM and 4GB Flash there is not really space for swap), the memory runs full by page-caching disk files.

There could be several ways out to ensure system is not crashing when pages for DMA are allocated by eg. XBMC, gplay or whatever wants to use the VPU.

1) continuously drop page cache (our measurement tells in our configuration every 15sec is fine even for 4K movies)
2) implement better dma page cache as v4l2 patch demonstrates (pre-alloc 256M and serve dma pages from there, use smart allocation as SmartHeap does and https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233 drafts ...)
3) modify vpu dma allocator to interfere with page cache and drop oldest cache entries
4) find a way to simulate swap-conditions without really paging out

Any hints choosing the optimal decision will be appreciated :)

Best regards
-- 
Jens Rehsack
rehsack@gmail.com

Re: Right lib-imx/firmware-imx ... versions

[John Weber]

Hi Jens-

On 8/2/14, 9:59 AM, Jens Rehsack wrote:
> Daiane, because you also was involved into https://community.freescale.com/thread/304414:
>
> I digged a lot deeper, tried https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233
> and debugged and proved more there ...
Have you forward-ported this to 3.10.17?  If so, it seems that the only downside 
for this is that it preallocates a lot of memory for the VPU.  It really 
shouldn't be necessary as long as page caching works properly, as I understand it.

> I also tried to get a picture of vmm by browsing "Understanding The Linux Virtual Memory Manager" by Mel Gorman.
>
> My result: When no swap is configured (and the box has none - because of 1GB RAM and 4GB Flash there is not really space for swap), the memory runs full by page-caching disk files.
Are you seeing some error messages here that you can post?
>
> There could be several ways out to ensure system is not crashing when pages for DMA are allocated by eg. XBMC, gplay or whatever wants to use the VPU.
>
> 1) continuously drop page cache (our measurement tells in our configuration every 15sec is fine even for 4K movies)
> 2) implement better dma page cache as v4l2 patch demonstrates (pre-alloc 256M and serve dma pages from there, use smart allocation as SmartHeap does and https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233 drafts ...)
> 3) modify vpu dma allocator to interfere with page cache and drop oldest cache entries
> 4) find a way to simulate swap-conditions without really paging out
This (4) seems like a hack.  We need to be able to turn off swap without having 
to simulate it.
>
> Any hints choosing the optimal decision will be appreciated :)
>
> Best regards

Re: Right lib-imx/firmware-imx ... versions

[Jens Rehsack]

Am 04.08.2014 um 17:41 schrieb John Weber <rjohnweber@gmail.com>:

> Hi Jens-
> 
> On 8/2/14, 9:59 AM, Jens Rehsack wrote:
>> Daiane, because you also was involved into https://community.freescale.com/thread/304414:
>> 
>> I digged a lot deeper, tried https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233
>> and debugged and proved more there ...
> Have you forward-ported this to 3.10.17?  If so, it seems that the only downside for this is that it preallocates a lot of memory for the VPU.  It really shouldn't be necessary as long as page caching works properly, as I understand it.

Today we received a BSP for our board for 3.10.17 - we might try it after first field test lunch (we want to see applications running - so this is just a side-theater :)
Important, but ... you know 8)

>> I also tried to get a picture of vmm by browsing "Understanding The Linux Virtual Memory Manager" by Mel Gorman.
>> 
>> My result: When no swap is configured (and the box has none - because of 1GB RAM and 4GB Flash there is not really space for swap), the memory runs full by page-caching disk files.
> Are you seeing some error messages here that you can post?

Precisely the same as in referred forum page - but IIRC a lot were posted earlier in the thread. I do not intend to spam list by reposting same information to often.
If you want, I prepare you a pastebin :)

>> There could be several ways out to ensure system is not crashing when pages for DMA are allocated by eg. XBMC, gplay or whatever wants to use the VPU.
>> 
>> 1) continuously drop page cache (our measurement tells in our configuration every 15sec is fine even for 4K movies)
>> 2) implement better dma page cache as v4l2 patch demonstrates (pre-alloc 256M and serve dma pages from there, use smart allocation as SmartHeap does and https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233 drafts ...)
>> 3) modify vpu dma allocator to interfere with page cache and drop oldest cache entries
>> 4) find a way to simulate swap-conditions without really paging out
> This (4) seems like a hack.  We need to be able to turn off swap without having to simulate it.

But we need to be able to kick cached pages when we need it - I'm quite unsure whether (4) is a hack or an improvement - why only swapping is permitted to drop caches?

Cheers
-- 
Jens Rehsack
rehsack@gmail.com

Re: Right lib-imx/firmware-imx ... versions

[John Weber]

On 8/4/14, 2:04 PM, Jens Rehsack wrote:
> Am 04.08.2014 um 17:41 schrieb John Weber <rjohnweber@gmail.com>:
>
>> Hi Jens-
>>
>> On 8/2/14, 9:59 AM, Jens Rehsack wrote:
>>> Daiane, because you also was involved into https://community.freescale.com/thread/304414:
>>>
>>> I digged a lot deeper, tried https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233
>>> and debugged and proved more there ...
>> Have you forward-ported this to 3.10.17?  If so, it seems that the only downside for this is that it preallocates a lot of memory for the VPU.  It really shouldn't be necessary as long as page caching works properly, as I understand it.
> Today we received a BSP for our board for 3.10.17 - we might try it after first field test lunch (we want to see applications running - so this is just a side-theater :)
> Important, but ... you know 8)
Yes - it would be good to see how this affects your system stability.  If it 
makes sense then perhaps we should have this integrated into the Wandboard kernel.
>>> I also tried to get a picture of vmm by browsing "Understanding The Linux Virtual Memory Manager" by Mel Gorman.
>>>
>>> My result: When no swap is configured (and the box has none - because of 1GB RAM and 4GB Flash there is not really space for swap), the memory runs full by page-caching disk files.
>> Are you seeing some error messages here that you can post?
> Precisely the same as in referred forum page - but IIRC a lot were posted earlier in the thread. I do not intend to spam list by reposting same information to often.
> If you want, I prepare you a pastebin :)
I'll see if I can dig back in the list.  Thanks.
>
>>> There could be several ways out to ensure system is not crashing when pages for DMA are allocated by eg. XBMC, gplay or whatever wants to use the VPU.
>>>
>>> 1) continuously drop page cache (our measurement tells in our configuration every 15sec is fine even for 4K movies)
>>> 2) implement better dma page cache as v4l2 patch demonstrates (pre-alloc 256M and serve dma pages from there, use smart allocation as SmartHeap does and https://github.com/wandboard-org/linux/commit/7cbd06b2904c1855109084ca6b0c84990bc69233 drafts ...)
>>> 3) modify vpu dma allocator to interfere with page cache and drop oldest cache entries
>>> 4) find a way to simulate swap-conditions without really paging out
>> This (4) seems like a hack.  We need to be able to turn off swap without having to simulate it.
> But we need to be able to kick cached pages when we need it - I'm quite unsure whether (4) is a hack or an improvement - why only swapping is permitted to drop caches?
Exactly.  I think you should be able to disable swap and still drop caches.