All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nagal, Amit               UTC CCS" <Amit.Nagal@utc.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Alexander Duyck <alexander.duyck@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"CHAWLA, RITU UTC CCS" <RITU.CHAWLA@utc.com>,
	"Netter, Christian M UTC CCS" <christian.Netter@fs.UTC.COM>
Subject: RE: [External] Re: linux kernel page allocation failure and tuning of page cache
Date: Mon, 3 Jun 2019 15:12:17 +0000	[thread overview]
Message-ID: <8e23b0efaf0e43f2aa0a1fc4846f6b02@UUSALE1A.utcmail.com> (raw)
In-Reply-To: 20190603121138.GC23346@bombadil.infradead.org



From: Matthew Wilcox [mailto:willy@infradead.org]
Sent: Monday, June 3, 2019 5:42 PM
To: Nagal, Amit UTC CCS <Amit.Nagal@utc.com>
On Mon, Jun 03, 2019 at 05:30:57AM +0000, Nagal, Amit               UTC CCS wrote:
> > [  776.174308] Mem-Info:
> > [  776.176650] active_anon:2037 inactive_anon:23 isolated_anon:0 [ 
> > 776.176650]  active_file:2636 inactive_file:7391 isolated_file:32 [ 
> > 776.176650]  unevictable:0 dirty:1366 writeback:1281 unstable:0 [ 
> > 776.176650]  slab_reclaimable:719 slab_unreclaimable:724 [ 
> > 776.176650]  mapped:1990 shmem:26 pagetables:159 bounce:0 [ 
> > 776.176650]  free:373 free_pcp:6 free_cma:0 [  776.209062] Node 0 
> > active_anon:8148kB inactive_anon:92kB active_file:10544kB 
> > inactive_file:29564kB unevictable:0kB isolated(anon):0kB 
> > isolated(file):128kB mapped:7960kB dirty:5464kB writeback:5124kB 
> > shmem:104kB writeback_tmp:0kB unstable:0kB pages_scanned:0 
> > all_unreclaimable? no [  776.233602] Normal free:1492kB min:964kB 
> > low:1204kB high:1444kB active_anon:8148kB inactive_anon:92kB 
> > active_file:10544kB inactive_file:29564kB unevictable:0kB 
> > writepending:10588kB present:65536kB managed:59304kB mlocked:0kB 
> > slab_reclaimable:2876kB slab_unreclaimable:2896kB 
> > kernel_stack:1152kB pagetables:636kB bounce:0kB free_pcp:24kB 
> > local_pcp:24kB free_cma:0kB [  776.265406] lowmem_reserve[]: 0 0 [ 
> > 776.268761] Normal: 7*4kB (H) 5*8kB (H) 7*16kB (H) 5*32kB (H) 6*64kB
> > (H) 2*128kB (H) 2*256kB (H) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 
> > 1492kB
> > 10071 total pagecache pages
> > [  776.284124] 0 pages in swap cache [  776.287446] Swap cache
> > stats: add 0, delete 0, find 0/0 [ 776.292645] Free swap  = 0kB [ 
> > 776.295532] Total swap = 0kB [ 776.298421] 16384 pages RAM [ 
> > 776.301224] 0 pages HighMem/MovableOnly [  776.305052] 1558 pages 
> > reserved
> >
> > 6) we have certain questions as below :
> > a) how the kernel memory got exhausted ? at the time of low memory conditions in kernel , are the kernel page flusher threads , which should have written dirty pages from page cache to flash disk , not > >executing at right time ? is the kernel page reclaim mechanism not executing at right time ?
> 
> >I suspect the pages are likely stuck in a state of buffering. In the case of sockets the packets will get queued up until either they can be serviced or the maximum size of the receive buffer as been exceeded >and they are dropped.
> 
> My concern here is that why the reclaim procedure has not triggered ?

>It has triggered.  1281 pages are under writeback.
Thanks for the reply .

Also , on target , cat /proc/sys/vm/min_free_kbytes = 965 .  As per https://www.kernel.org/doc/Documentation/sysctl/vm.txt  , the minimum value min_free_kbytes  should be set must be 1024 . 
is this min_free_kbytes setting creating the problem ?

Target is having 64MB memory  , what value is recommended for setting min_free_kbytes  ?

also is this a problem if the process receiving socket data is run at elevated priority ( we set it firstly  chrt -r 20 and then changed it later to renice -n -20) I observed lru-add-drain , writeback threads were executing at normal priority .

what I mean above is 2 separate iterations for process priority settings ( 1st iteration :: chrt -r 20  , 2nd iteration : renice -n -20 , there was no iteration in which both chrt and renice were used together) . 
although in  both priority settings , we got the page allocation failure problem .












  parent reply	other threads:[~2019-06-03 15:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-31 15:07 linux kernel page allocation failure and tuning of page cache Nagal, Amit               UTC CCS
2019-05-31 19:30 ` Matthew Wilcox
2019-05-31 19:30   ` Matthew Wilcox
2019-06-03  5:37   ` [External] " Nagal, Amit               UTC CCS
2019-06-03  5:37     ` Nagal, Amit               UTC CCS
2019-06-03 10:32   ` Nagal, Amit               UTC CCS
2019-06-03 10:32     ` Nagal, Amit               UTC CCS
2019-05-31 21:27 ` Alexander Duyck
2019-05-31 21:27   ` Alexander Duyck
2019-06-03  5:30   ` [External] " Nagal, Amit               UTC CCS
2019-06-03  5:30     ` Nagal, Amit               UTC CCS
2019-06-03 12:11     ` Matthew Wilcox
2019-06-03 12:11       ` Matthew Wilcox
2019-06-03 14:49       ` Nagal, Amit               UTC CCS
2019-06-03 14:49         ` Nagal, Amit               UTC CCS
2019-06-03 15:12       ` Nagal, Amit               UTC CCS [this message]
2019-06-03 15:12         ` Nagal, Amit               UTC CCS

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=8e23b0efaf0e43f2aa0a1fc4846f6b02@UUSALE1A.utcmail.com \
    --to=amit.nagal@utc.com \
    --cc=RITU.CHAWLA@utc.com \
    --cc=alexander.duyck@gmail.com \
    --cc=christian.Netter@fs.UTC.COM \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.