From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 27A8DE004DD; Mon, 4 Aug 2014 08:41:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (rjohnweber[at]gmail.com) * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [209.85.160.177 listed in list.dnswl.org] Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id B4328E0030B for ; Mon, 4 Aug 2014 08:41:22 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id 79so4189521ykr.22 for ; Mon, 04 Aug 2014 08:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=lQZRa6SpNd2HQ8AeGTw7g3oTLr+yiqCVtmLYYhnqDQ0=; b=lUEb19Lou5YVfSPbP6sl3RpwchwXIoum+ijtegTMn1+vXgp8WrZbJc3LE4qtK8mGwS wd76USGUAUKjPDTq+e70wJ3K5WRTwhw6dJdgeAJexy38mjzmnjXoHvl176CJz2v2j76q RS0EFM9a1KP1LIzJB89ywQGWG76Hrxt3Q7+jPxln/hInCOSGRf41TgnkZqPLFGZwYBsI Dt97OjELwmPuOEoZkJxhI8XmZ64P4De/TEWLqpAgq2KLJ7E11uGfzAWGLSBAsDkiEpQD zDmNSPysh6xN2y8AA5AhLUNVCTn0UDDj9IYV/F9NR4I+FckmsnZPvFoXwCRiXqXc8F/X GTvA== X-Received: by 10.236.131.136 with SMTP id m8mr3836115yhi.198.1407166882489; Mon, 04 Aug 2014 08:41:22 -0700 (PDT) Received: from goober-2.local ([75.76.45.160]) by mx.google.com with ESMTPSA id d46sm30652105yha.10.2014.08.04.08.41.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 08:41:22 -0700 (PDT) Message-ID: <53DFA9A1.8060007@gmail.com> Date: Mon, 04 Aug 2014 10:41:21 -0500 From: John Weber User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: meta-freescale@yoctoproject.org References: <04142B7D-669C-4114-A990-CEC915F8ECF2@gmail.com> In-Reply-To: <04142B7D-669C-4114-A990-CEC915F8ECF2@gmail.com> Subject: Re: Right lib-imx/firmware-imx ... versions X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 15:41:28 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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