<font size=2 face="sans-serif">It might be the case that </font><font size=2 face="Tahoma">AsynchronousFileChannel</font><font size=2 face="sans-serif">is actually doing mmap access to the files. Thus, the memory management
will be completely different with GPFS in compare to local fs.</font><br><font size=2 face="sans-serif"><br>Regards,<br><br>Tomer Perry<br>Scalable I/O Development (Spectrum Scale)<br>email: tomp@il.ibm.com<br>1 Azrieli Center, Tel Aviv 67021, Israel<br>Global Tel: +1 720 3422758<br>Israel Tel: +972 3 9188625<br>Mobile: +972 52 2554625<br></font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Jim Doherty <jjdoherty@yahoo.com></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">gpfsug main discussion
list <gpfsug-discuss@spectrumscale.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">06/03/2019 06:59</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [gpfsug-discuss]
Memory accounting for processes writing to GPFS</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><font size=2 face="Helvetica">For any process with a large number of
threads the VMM size has become an imaginary number ever since the glibc
change to allocate a heap per thread. </font><br><font size=2 face="Helvetica">I look to /proc/$pid/status to find the
memory used by a proc RSS + Swap + kernel page tables. </font><br><br><font size=2 face="Helvetica">Jim</font><br><br><font size=2 color=#2f2f2f face="Helvetica Neue">On Wednesday, March
6, 2019, 4:25:48 AM EST, Dorigo Alvise (PSI) <alvise.dorigo@psi.ch>
wrote: </font><br><br><br><font size=2 face="Tahoma">Hello to everyone,</font><br><font size=2 face="Tahoma">Here a PSI we're observing something that
in principle seems strange (at least to me).</font><br><font size=2 face="Tahoma">We run a Java application writing into disk
by mean of a standard AsynchronousFileChannel, whose I do not the details.</font><br><font size=2 face="Tahoma">There are two instances of this application:
one runs on a node writing on a local drive, the other one runs writing
on a GPFS mounted filesystem (this node is part of the cluster, no remote-mounting).</font><br><br><font size=2 face="Tahoma">What we do see is that in the former the
application has a lower sum VIRT+RES memory and the OS shows a really big
cache usage; in the latter, OS's cache is negligible while VIRT+RES is
very (even too) high (with VIRT very high).</font><br><br><font size=2 face="Tahoma">So I wonder what is the difference... Writing
into a GPFS mounted filesystem, as far as I understand, implies "talking"
to the local mmfsd daemon which fills up its own pagepool... and then the
system will asynchronously handle these pages to be written on real pdisk.
But why the Linux kernel accounts so much memory to the process itself
? And why this large amount of memory is much more VIRT than RES ?</font><br><br><font size=2 face="Tahoma">thanks in advance,</font><br><br><font size=2 face="Tahoma"> Alvise</font><br><font size=2 color=#2f2f2f face="Helvetica Neue">_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org</font><font size=2 color=blue face="Helvetica Neue"><u><br></u></font><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank"><font size=2 color=blue face="Helvetica Neue"><u>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</u></font></a><tt><font size=2>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br></font></tt><br><br><BR>