On Tue, 2019-08-20 at 22:20 +0200, Alexander Kanavin wrote:
> On Tue, 20 Aug 2019 at 15:46, Mark Hatle
> wrote:
> > Looking at what my customers are doing, I completely agree. I look
> > at the
> > design criteria for my customer's devices and I'm seeing 256MB as
> > -very- common.
> > More happ
On 8/20/19 11:38 AM, Adrian Bunk wrote:
> On Tue, Aug 20, 2019 at 08:46:53AM -0500, Mark Hatle wrote:
>> On 8/19/19 9:55 AM, richard.pur...@linuxfoundation.org wrote:
>>> On Mon, 2019-08-19 at 16:01 +0200, Alexander Kanavin wrote:
Should the limit be simply raised? The 256M setup is crumbling
On Tue, 20 Aug 2019 at 15:46, Mark Hatle wrote:
> Looking at what my customers are doing, I completely agree. I look at the
> design criteria for my customer's devices and I'm seeing 256MB as -very-
> common.
> More happens, but it's rare still. (But I have some customers with GB of
> ram,
> b
On Tue, Aug 20, 2019 at 08:46:53AM -0500, Mark Hatle wrote:
> On 8/19/19 9:55 AM, richard.pur...@linuxfoundation.org wrote:
> > On Mon, 2019-08-19 at 16:01 +0200, Alexander Kanavin wrote:
> >> Should the limit be simply raised? The 256M setup is crumbling on
> >> several fronts (runtime tests, mode
On 8/19/19 9:55 AM, richard.pur...@linuxfoundation.org wrote:
> On Mon, 2019-08-19 at 16:01 +0200, Alexander Kanavin wrote:
>> Should the limit be simply raised? The 256M setup is crumbling on
>> several fronts (runtime tests, modernisation of X, various non-x86
>> qemu targets). Adding per-image/t
On Mon, 19 Aug 2019 at 16:55, wrote:
> I'd even possibly accept a case for higher memory defaults for graphics
> images when GL is enabled. Pushing the default qemu memory size to
> 512MB everywhere is wrong though and sends out the wrong message for
> the project.
>
Thanks for the response (I d
On Mon, 2019-08-19 at 16:01 +0200, Alexander Kanavin wrote:
> Should the limit be simply raised? The 256M setup is crumbling on
> several fronts (runtime tests, modernisation of X, various non-x86
> qemu targets). Adding per-image/target exceptions, custom non-
> upstreamable patches, or sticking t
Probably in this case it is better to add a patch that allows
HIGH_RLIMIT_NOFILE to be configured from the systemd recipe via meson
switches, and offer that to systemd upstream.
Alex
On Mon, 19 Aug 2019 at 16:25, Hongxu Jia wrote:
> On 8/19/19 10:01 PM, Alexander Kanavin wrote:
>
> Should the l
On 8/19/19 10:01 PM, Alexander Kanavin wrote:
Should the limit be simply raised? The 256M setup is crumbling on
several fronts (runtime tests, modernisation of X, various non-x86
qemu targets). Adding per-image/target exceptions, custom
non-upstreamable patches, or sticking to deprecated config
Should the limit be simply raised? The 256M setup is crumbling on several
fronts (runtime tests, modernisation of X, various non-x86 qemu targets).
Adding per-image/target exceptions, custom non-upstreamable patches, or
sticking to deprecated configurations isn't the right thing to do, I think.
Al
Since do_testimage for core-image-sato-sdk has memory limitation (256Mib)
which caused rpc.statd failed with out of memory.
[ 531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or
sacrifice child
The rpc.statd allocates memory according to RLIMIT_NOFILE,
so decrease it to 4k to ke
11 matches
Mail list logo
