linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: PINTU KUMAR <pintu_agarwal@yahoo.com>
To: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"pintu.k@samsung.com" <pintu.k@samsung.com>,
	Anton Vorontsov <anton.vorontsov@linaro.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	richard -rw- weinberger <richard.weinberger@gmail.com>,
	"patches@linaro.org" <patches@linaro.org>,
	Mel Gorman <mgorman@suse.de>,
	Wanpeng Li <liwanp@linux.vnet.ibm.com>
Subject: Re: Introducing Aggressive Low Memory Booster [1]
Date: Sun, 20 Jan 2013 08:03:53 -0800 (PST)	[thread overview]
Message-ID: <1358697833.56285.YahooMailNeo@web160102.mail.bf1.yahoo.com> (raw)
In-Reply-To: <1358091177.96940.YahooMailNeo@web160103.mail.bf1.yahoo.com>

Hi,

Can anybody provide any inputs/suggestions/improvements on the following.

According to my experiments these proved to be a useful utility during low memory condition on the embedded devices.
Is there something wrong I am doing?

Please provide your suggestions.

Thanks,
Pintu



>________________________________
> From: PINTU KUMAR <pintu_agarwal@yahoo.com>
>To: "linux-mm@kvack.org" <linux-mm@kvack.org>; "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> 
>Cc: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>; "pintu.k@samsung.com" <pintu.k@samsung.com>; Anton Vorontsov <anton.vorontsov@linaro.org>; Alan Cox <alan@lxorguk.ukuu.org.uk>; richard -rw- weinberger <richard.weinberger@gmail.com>; "patches@linaro.org" <patches@linaro.org>; Mel Gorman <mgorman@suse.de>; Wanpeng Li <liwanp@linux.vnet.ibm.com> 
>Sent: Sunday, 13 January 2013 9:02 PM
>Subject: Introducing Aggressive Low Memory Booster [1]
> 
>
>Hi,
>
>
>Here I am trying to introduce a new feature in kernel called "Aggressive Low Memory Booster".
>The main advantage of this will be to boost the available free memory of the system to "certain level" during extremely low memory condition.
>
>
>Please provide your comments to improve further.
>Can it be used along with vmpressure_fd ???
>
>
>
>It can be invoked as follows:
>    a) Automatically by kernel memory management when the memory threshold falls below 10MB.
>    b) From user space program/scripts by passing the "required amount of memory to be reclaimed".
>    Example: echo 100 > /dev/shrinkmem
>    c) using sys interface - /sys/kernel/debug/shrinkallmem
>    d) using an ioctl call and returning number of pages reclaimed.
>    e) using a new system call - shrinkallmem(&nrpages);
>    f) During CMA to reclaim and shrink a specific CMA regions.
>
>
>
>I have developed a kernel module to verify the (b) part.
>
>
>Here is the snapshot of the write call:
>+static ssize_t shrinkmem_write(struct file *file, const char *buff,
>+                                size_t length, loff_t *pos)
>+{
>+        int ret = -1;
>+        unsigned long memsize = 0;
>+        unsigned long nr_reclaim = 0;
>+        unsigned long pages = 0;
>+        ret = kstrtoul_from_user(buff, length, 0, &memsize);
>+        if (ret < 0) {
>+                printk(KERN_ERR "[SHRINKMEM]: kstrtoul_from_user: Failed !\n");
>+                return
-1;
>+        }
>+        printk(KERN_INFO "[SHRINKMEM]: memsize(in MB) = %ld\n",
>+                                (unsigned long)memsize);
>+        memsize = memsize*(1024UL*1024UL);
>+        nr_reclaim = memsize / PAGE_SIZE;
>+        pages = shrink_all_memory(nr_reclaim);
>+        printk(KERN_INFO "<SHRINKMEM>: Number of Pages Freed: %lu\n", pages);
>+        return pages;
>+}
>Please note: This requires CONFIG_HIBERNATION to be permanently enabled in the kernel.
>
>
>Several experiments have been performed on Ubuntu(kernel 3.3) to verify it under low memory conditions.
>
>
>Following are some results obtained:
>-------------------------------------
>
>Node 0, zone      DMA    290    115      0      0      0      0      0      0      0      0      0
>Node 0, zone   Normal    304    540    116     13      2      2      0      0      0      0      0
>=========================
>             total      
used       free     shared    buffers     cached
>Mem:           497        487         10          0         63        303
>-/+ buffers/cache:        120        376
>Swap:         1458         34       1424
>Total:        1956        522       1434
>=========================
>Total Memory Freed: 342 MB
>Total Memory Freed: 53 MB
>Total
Memory Freed: 23 MB
>Total Memory Freed: 10 MB
>Total Memory Freed: 15 MB
>Total Memory Freed: -1 MB
>Node 0, zone      DMA      6      6      7      8     10      9      7      4      1      0      0
>Node 0, zone   Normal   2129   2612   2166   1723   1260    759    359    108     10      0      0
>=========================
>             total      
used       free     shared    buffers     cached
>Mem:           497         47        449          0          0          5
>-/+ buffers/cache:         41        455
>Swap:         1458         97       1361
>Total:        1956        145       1811
>=========================
>
>
>It was verified using a sample shell script "reclaim_memory.sh" which keeps recovering memory by doing "echo 500 > /dev/shrinkmem" until no further reclaim is possible.
>
>
>The experiments were performed with various scenarios as follows:
>a) Just after the boot up - (could recover around 150MB with 512MB RAM)
>b) After running many applications include youtube videos, large tar files download - 
>
>   [until free mem becomes < 10MB]
>   [Could recover around 300MB in one shot]
>c) Run reclaim, while download is in progress and video still playing - (Not applications killed)
>
>d) revoke all background applications again, after running reclaim - (No impact, normal behavior)
>   [Just it took little extra time to launch, as if it was launched for first time]
>
>
>
>
>Please see more discussions on this in the last year mailing list:
>
>https://lkml.org/lkml/2012/4/15/35
>
>
>
>Thank You!
>With regards,
>Pintu Kumar
>Samsung - India
>
>
>
>
>
>

  parent reply	other threads:[~2013-01-20 16:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-15  9:47 [NEW]: Introducing shrink_all_memory from user space 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
     [not found]           ` <1358091177.96940.YahooMailNeo@web160103.mail.bf1.yahoo.com>
2013-01-14 11:00             ` Introducing Aggressive Low Memory Booster [1] Bartlomiej Zolnierkiewicz
2013-01-20 16:03             ` PINTU KUMAR [this message]
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

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=1358697833.56285.YahooMailNeo@web160102.mail.bf1.yahoo.com \
    --to=pintu_agarwal@yahoo.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=anton.vorontsov@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liwanp@linux.vnet.ibm.com \
    --cc=mgorman@suse.de \
    --cc=patches@linaro.org \
    --cc=pintu.k@samsung.com \
    --cc=richard.weinberger@gmail.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;
as well as URLs for NNTP newsgroup(s).