<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Yes, it uses a large value for virtual size.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Since I can run it via terminal (outside of slurm), I think kernel parameters are OK.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">In other words, I have to configure slurm for that purpose.</div><div class="gmail_default" style="font-family:tahoma,sans-serif">Which slurm configuration parameter is in charge of that?<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font face="tahoma,sans-serif">Regards,<br>Mahmood</font><br><br><br></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 24, 2020 at 5:22 PM Jeffrey T Frey <<a href="mailto:frey@udel.edu">frey@udel.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Does your Slurm cgroup or node OS cgroup configuration limit the virtual address space of processes?  The "Error memory mapping" is thrown by blast when trying to create a virtual address space that exposes the contents of a file on disk (see "man mmap") so the file can be accessed via pointers (with the OS handling paging data in and out of the file on disk) rather than by means of standard file i/o calls (e.g. fread(), fscanf(), read()).  It sounds like you don't have enough system RAM, period, or the cgroup "memory.memsw.limit_in_bytes" is set too low for the amount of file content you're attempting to mmap() into the virtual address space (e.g. BIG files).<br>
<br>
<br>
<br>
</blockquote></div></div>