public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "pidsouza at in dot ibm.com" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug libc/13570] New: Controlling gmon.out file creation in HPC environment Date: Fri, 06 Jan 2012 18:32:00 -0000 [thread overview] Message-ID: <bug-13570-131@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=13570 Bug #: 13570 Summary: Controlling gmon.out file creation in HPC environment Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: drepper.fsp@gmail.com ReportedBy: pidsouza@in.ibm.com Classification: Unclassified In the High Performance Computing (HPC) the parallel(Message Passing Interface - MPI) applications run as large number of tasks (100s, 1000s to 1 million tasks). Each of these tasks may be run on different nodes of a HPC cluster. Each task is a process by itself, which are executed in parallel using the same binary (SPMD or MPMD models). When these MPI applications are profiled using -pg option, depending on the number of tasks those many separate gmon.out files will be created in the same shared file system. This leads to bottleneck on to the application both from file system space, large amount disk operation during process exit. HPC users might be interested in limited set of gmon.out files which meet certain defined criteria and not all the gmon.out files created. However the set is not known until after the application has completed execution and the gmon.out files are about to be written. In the view to address the above said bottleneck and give the user only the gmon.out files of interest, following approach can be thought about: 1. Disable the generation of gmon.out file at exit(). 2. Obtain access to all gmon data in memory prior to application exit using public interfaces so that data can be processed for the subset of tasks that are of interest. The above approach was tried on Redhat 6.1 (Santiago) 2.6.32-131.0.15.el6.ppc64. With moncontrol(0) could not stop the creation of gmon.out file during exit. It only switches off the profiling. The atexit handler gmon.c:_mcleanup() creates the gmon.out. There is no way to stop it creating. Even if one succeeds to stop creation of gmon.out file, the data variable which holds the profile data is declared as hidden. Ref - gmon.c:struct gmonparam _gmonparam attribute_hidden = { GMON_PROF_OFF }; Due to this, the applications will not be able to read the collected in-memory data from the tasks to apply the filtering criteria. We need mechanisms to stop the creation of gmon.out file and access to read the collected gmon data using which gmon.out file is generated at will. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
next reply other threads:[~2012-01-06 18:32 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-01-06 18:32 pidsouza at in dot ibm.com [this message] 2012-12-19 10:50 ` [Bug libc/13570] " schwab@linux-m68k.org 2013-10-26 6:03 ` neleai at seznam dot cz 2014-06-27 11:14 ` fweimer at redhat dot com
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=bug-13570-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.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: linkBe 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 read-only IMAP folder(s) and NNTP newsgroup(s).