Received: by 10.192.165.148 with SMTP id m20csp492211imm; Fri, 27 Apr 2018 02:31:53 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrVbthLh8qE8fG1i5WZWGe7BtRYR29UCp+LBNg0psKHxDwthNE0y6sNOM+NJKqZJrFhdqF9 X-Received: by 2002:a65:4083:: with SMTP id t3-v6mr1485481pgp.129.1524821512964; Fri, 27 Apr 2018 02:31:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524821512; cv=none; d=google.com; s=arc-20160816; b=WE4Xk+DOvw0W+2Fwrc27NUyR0/ThYvL4LOj6ZyxX3ca+6iy23f6uVDsduCT1Zjh0mE 1jycKFSYUJIN7XxJgq+sl7zXuA3XDP+bQIw9q92VG/pKj5cIkjZTUaUDvIwuuzw4xOuZ lZrlPq4CjAxL9sPXh0HJhDrgQPYSDl2nwWHo+qMMY6Hx5hup8cZ5dOmU9Nnu5sNKVWpz spG5fQ07USs2+nPCaiW8BKNBE1cowtMGz1h7koO2hlzDItUjnsaV7cDv/2FGKIL+4XA0 krchqaZX+T1sf6cPKdFy/h3vjqo1OtNEQlF+LkirujAK6/kniYx7Jg47VsfTj1OhFX/b uVgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=lD9OoKyQypebpIqMh5y7nn1AKRd0CrTxryKhxvEuecs=; b=WCY8G5+CXVkeOl2h1BaNnb1W9jhOFZRwrWYgvGBE2a0PiZfGvSTVJ2ahkQ7/37K6Jc krGD/ZNlrnpnBs3Yu8zO///qIaZOBPMfGXz4T9ACK1r9bN353z68u1CvWPBYum7v9Fhz oBbcei5TGhUluG0K1WLMvcbUM8n/QbX/SWpKeAINnYyTkp/uvOMCPYj9mCgvrngx/Oe1 o49x5P9xjInDsZmkzV+UvXAfLlaEUGad0fjEYM+Kcx3HImmb3MX5tQNPbwntqH2tin9b CjbrCulNIRU5sXl5FJ1CRAaZbOYLuAoAAkgQXmi1fJXr3xzaBEV97KOxKC7ZFFigvvmp QnXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=E2emme6P; dkim=pass header.i=@codeaurora.org header.s=default header.b=b8s/aIOS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 132-v6si880704pgb.470.2018.04.27.02.31.39; Fri, 27 Apr 2018 02:31:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=E2emme6P; dkim=pass header.i=@codeaurora.org header.s=default header.b=b8s/aIOS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932439AbeD0J3e (ORCPT + 99 others); Fri, 27 Apr 2018 05:29:34 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:42076 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757873AbeD0J3d (ORCPT ); Fri, 27 Apr 2018 05:29:33 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 965F360314; Fri, 27 Apr 2018 09:29:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1524821372; bh=6Q+vJ9x4Jfw8abdFJsRe27J/fr+qVUsYK4VSlYqzouU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=E2emme6PvnXLKDyPcIX0lZPndfrQsH49X1rtV9SH/rImVSd0Prw4ZhR7o5tkIrYoj eIF9Ft0f+odOhUj8iWjkV0ltzaM44yhbWcCdqks/HHAd7B2kmAOFXWncVfic3fmCeY 2hlPtFoOPXFgFe6nqMU8IiY0+/ySuUJbJAvo0ou4= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id BABE860314; Fri, 27 Apr 2018 09:29:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1524821371; bh=6Q+vJ9x4Jfw8abdFJsRe27J/fr+qVUsYK4VSlYqzouU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=b8s/aIOSnn0/jcRFWXrrDbPJi7BHP/Qi2qYAJCz+PL6mbQexzPgjk7LIV9s1VtVYv /fU7jaoI6FlrCysP45XMQI+tfd9/dg5uzyUORcQ1m40etASRjOHjWVyiKnJjXmNDNP 5ES7hW4YdbhnA7vHBR+hQuU3RLnbpOSC0pBzOnPA= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 27 Apr 2018 14:59:31 +0530 From: vjitta@codeaurora.org To: Laura Abbott Cc: sumit.semwal@linaro.org, gregkh@linuxfoundation.org, arve@android.com, tkjos@android.com, maco@android.com, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, linux-kernel-owner@vger.kernel.org Subject: Re: [PATCH] ion: Consider ion pool pages as indirectly reclaimable In-Reply-To: References: <1524627830-17187-1-git-send-email-vjitta@codeaurora.org> <8618859b-06f9-39a7-80a9-af36cf9faf9f@redhat.com> Message-ID: X-Sender: vjitta@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-04-27 10:40, vjitta@codeaurora.org wrote: > On 2018-04-25 21:17, Laura Abbott wrote: >> On 04/24/2018 08:43 PM, vjitta@codeaurora.org wrote: >>> From: Vijayanand Jitta >>> >>> An issue is observed where mallocs are failing due to overcommit >>> failure. >>> The failure happens when there is high ION page pool since ION page >>> pool is not considered reclaimable by the overcommit calculation >>> code. >>> This change considers ion pool pages as indirectly reclaimable and >>> thus >>> accounted as available memory in the overcommit calculation. >>> >>> Signed-off-by: Vijayanand Jitta >>> --- >>> drivers/staging/android/ion/ion_page_pool.c | 5 +++++ >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/drivers/staging/android/ion/ion_page_pool.c >>> b/drivers/staging/android/ion/ion_page_pool.c >>> index db8f614..9bc56eb 100644 >>> --- a/drivers/staging/android/ion/ion_page_pool.c >>> +++ b/drivers/staging/android/ion/ion_page_pool.c >>> @@ -32,6 +32,9 @@ static void ion_page_pool_add(struct ion_page_pool >>> *pool, struct page *page) >>> list_add_tail(&page->lru, &pool->low_items); >>> pool->low_count++; >>> } >>> + >>> + mod_node_page_state(page_pgdat(page), >>> NR_INDIRECTLY_RECLAIMABLE_BYTES, >>> + (1 << (PAGE_SHIFT + pool->order))); >>> mutex_unlock(&pool->mutex); >>> } >>> @@ -50,6 +53,8 @@ static struct page *ion_page_pool_remove(struct >>> ion_page_pool *pool, bool high) >>> } >>> list_del(&page->lru); >>> + mod_node_page_state(page_pgdat(page), >>> NR_INDIRECTLY_RECLAIMABLE_BYTES, >>> + -(1 << (PAGE_SHIFT + pool->order))); >>> return page; >>> } >>> >> >> I'm sure this fixes the problem but I don't think we want to >> start throwing page adjustments into Ion. Why isn't this >> memory already considered reclaimable by existing calculations? >> >> Thanks, >> Laura > > You can refer to discussion here https://lkml.org/lkml/2018/3/5/361 > introducing > NR_INDIRECTLY_RECLAIMABLE_BYTES for the memory which is not currently > considered > as reclaimable > > Thanks, > Vijay There was also discussion specific to ion in that thread you can find it here https://lkml.org/lkml/2018/4/25/642 Thanks, Vijay