From: Matthew Wilcox [mailto:[email protected]]
Sent: Monday, June 3, 2019 5:42 PM
To: Nagal, Amit UTC CCS <[email protected]>
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 .
