From: Laura Abbott <labbott@redhat.com>
To: vjitta@codeaurora.org, sumit.semwal@linaro.org
Cc: gregkh@linuxfoundation.org, arve@android.com, tkjos@android.com,
maco@android.com, devel@driverdev.osuosl.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ion: Consider ion pool pages as indirectly reclaimable
Date: Wed, 25 Apr 2018 08:47:34 -0700 [thread overview]
Message-ID: <8618859b-06f9-39a7-80a9-af36cf9faf9f@redhat.com> (raw)
In-Reply-To: <1524627830-17187-1-git-send-email-vjitta@codeaurora.org>
On 04/24/2018 08:43 PM, vjitta@codeaurora.org wrote:
> From: Vijayanand Jitta <vjitta@codeaurora.org>
>
> 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 <vjitta@codeaurora.org>
> ---
> 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
next prev parent reply other threads:[~2018-04-25 15:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-25 3:43 vjitta
2018-04-25 15:47 ` Laura Abbott [this message]
2018-04-27 5:10 ` vjitta
2018-04-27 9:29 ` vjitta
2018-04-27 21:30 ` Laura Abbott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8618859b-06f9-39a7-80a9-af36cf9faf9f@redhat.com \
--to=labbott@redhat.com \
--cc=arve@android.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maco@android.com \
--cc=sumit.semwal@linaro.org \
--cc=tkjos@android.com \
--cc=vjitta@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®