From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: PINTU KUMAR <pintu_agarwal@yahoo.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"pintu.k@samsung.com" <pintu.k@samsung.com>
Subject: Re: [NEW]: Introducing shrink_all_memory from user space
Date: Wed, 18 Apr 2012 21:07:27 +0100 [thread overview]
Message-ID: <20120418210727.0d113647@pyramind.ukuu.org.uk> (raw)
In-Reply-To: <1334483226.20721.YahooMailNeo@web162003.mail.bf1.yahoo.com>
> 5) After running this on my system, the performance was improved quickly.
>
> 6) I performed the same experiment on our Samsung Smart phones as well. And I have seen a drastic improve in performance after running this for 3/4 times.
> In case of phones it is more helpful as there is no swap space.
>
> 7) Your feedback and suggestion is important. Based on the feedback, I can plan to submit the patches officially after performing basic cleanups.
So really I think this tells you two things
1. There are cases where the kernel paging subsystem is perhaps making
poor choices and should have forced out more read only pages.
2. For certain DMA allocation cases it might be a good idea to move the
interface out of the HIBERNATION config option and call it automatically
with the relevant memory allocator when requests for large linear
allocations would otherwise fail.
> This can be even using inside the multimedia drivers that requires large contiguous memory to check if that many memory pages can be reclaimed or not.
Yes - I agree. However the way that the memory is obtained and the use of
shrink_all_memory() should not be exposed as it breaks the abstraction.
If you can use it *within* the contiguous memory allocator so that the
driver does not know about shrink_all_memory, then this would be
interesting and potentially useful.
Alan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2012-04-18 20:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-15 9:47 PINTU KUMAR
2012-04-15 10:00 ` santosh
2012-04-15 10:38 ` richard -rw- weinberger
2012-04-15 11:47 ` PINTU KUMAR
2012-04-15 12:10 ` richard -rw- weinberger
2012-04-16 9:16 ` PINTU KUMAR
2012-04-18 20:10 ` Alan Cox
2012-04-19 13:42 ` PINTU KUMAR
2013-01-13 15:32 ` Introducing Aggressive Low Memory Booster [1] PINTU KUMAR
2013-01-14 11:00 ` Bartlomiej Zolnierkiewicz
2013-01-20 16:03 ` PINTU KUMAR
2012-04-16 18:50 ` [NEW]: Introducing shrink_all_memory from user space Ying Han
2012-04-17 18:24 ` KOSAKI Motohiro
2012-04-18 20:07 ` Alan Cox [this message]
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=20120418210727.0d113647@pyramind.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pintu.k@samsung.com \
--cc=pintu_agarwal@yahoo.com \
/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