From: Will C. <wc...@re...> - 2003-07-15 22:13:36
Attachments:
oprofile-0.5.4-sync.patch
|
On some occasions I have noticed empty sample files. The documentation for msync on linux says the following: DESCRIPTION msync flushes changes made to the in-core copy of a file that was mapped into memory using mmap(2) back to disk. Without use of this call there is no guarantee that changes are written back before munmap(2) is called. Shouldn't there be something like the attached patch in the daemon to make sure that the files are synced before they are closed? -Will |
From: John L. <le...@mo...> - 2003-07-15 23:34:00
|
On Tue, Jul 15, 2003 at 06:13:22PM -0400, Will Cohen wrote: > Shouldn't there be something like the attached patch in the daemon to > make sure that the files are synced before they are closed? I think so yes regards john |
From: Philippe E. <ph...@wa...> - 2003-07-15 23:59:17
|
Will Cohen wrote: > On some occasions I have noticed empty sample files. The documentation > for msync on linux says the following: have you a typical way to reproduce it, or it occurs from time to time only ? > > DESCRIPTION > msync flushes changes made to the in-core copy of a file > that was mapped into memory using mmap(2) back to disk. Without use > of this call there is no guarantee that changes are written back > before munmap(2) is called. > > Shouldn't there be something like the attached patch in the daemon to > make sure that the files are synced before they are closed? as I can read the man page imply you must msync if you want the change written back *before* munmap, this imply munmap sync the file. The mmap manpage says about munmap and MAP_SHARED use: MAP_SHARED Share this mapping with all other processes that map this object. Storing to the region is equivalent to writing to the file. The file may not actually be updated until msync(2) or munmap(2) are called > --- oprofile-0.5.4/daemon/oprofiled.c.sync 2003-07-15 18:02:19.000000000 -0400 > +++ oprofile-0.5.4/daemon/oprofiled.c 2003-07-15 18:02:41.000000000 -0400 > @@ -542,6 +542,7 @@ > close(2); > opd_open_logfile(); > /* We just close them, and re-open them lazily as usual. */ > + opd_for_each_image(opd_sync_image_samples_files); > opd_for_each_image(opd_close_image_samples_files); opd_close_image_samples_files --> odb_close --> munmap, I don't think the msync is usefull. regards, Phil |
From: Will C. <wc...@re...> - 2003-07-16 00:24:06
|
Philippe Elie wrote: > Will Cohen wrote: > >> On some occasions I have noticed empty sample files. The documentation >> for msync on linux says the following: > > > have you a typical way to reproduce it, or it occurs from > time to time only ? Unfortunately, I don't have a consistent way of reproducing the problem. I have just ocassionally noticed sample files of length zero. Honestly, I don't know if what I suggested is guaranteed to fix the problem. I noticed this on a sample session when starting up oprofile in rc.sysinit with "--verbose" and shutting it down in "rc.local". It doesn't happen everytime. Because I had "--verbose" I saw the end of oprofile.log (the stats were right after this, no additional samples listed in the oprofile.log): Opening image "/lib/ld-2.3.2.so" for app "/usr/bin/oprofiled" COOKIE_SWITCH to cookie 4279268 (/lib/ld-2.3.2.so) Putting image sample (/lib/ld-2.3.2.so) offset 0x154fe, counter 0 Opening "/var/lib/oprofile/samples//}usr}bin}oprofiled}}}lib}ld-2.3.2.so#0" This was oprofile 0.5.4 and op_time doesn't handle zero length sample files. > as I can read the man page imply you must msync if you want the > change written back *before* munmap, this imply munmap sync the > file. > > The mmap manpage says about munmap and MAP_SHARED use: > > > MAP_SHARED Share this mapping with all other processes > that map this object. Storing to the region is > equivalent to writing to the file. The file > may not actually be updated until msync(2) or > munmap(2) are called fair enough, munmap implies msync. However, it still looks like there some kind of race condition causing zero length sample files. -Will |
From: John L. <le...@mo...> - 2003-07-16 00:35:37
|
On Tue, Jul 15, 2003 at 08:23:52PM -0400, Will Cohen wrote: > fair enough, munmap implies msync. However, it still looks like there > some kind of race condition causing zero length sample files. There was one in earlier releases that caused an open by pp tools to race against a daemon write ... regards john |
From: Philippe E. <ph...@wa...> - 2003-07-16 01:57:57
|
John Levon wrote: > On Tue, Jul 15, 2003 at 08:23:52PM -0400, Will Cohen wrote: > > >>fair enough, munmap implies msync. However, it still looks like there >>some kind of race condition causing zero length sample files. > > > There was one in earlier releases that caused an open by pp tools to > race against a daemon write ... There is a small but un-avoidable race when creating the samples file between creation and initialization but this race can occur only if the profiler is running. There is also a note in TODO about opcontrol --reset. As Will you sugggested opreport would probably ignore zero length samples files (silently ?) ... regards, Phil |
From: Will C. <wc...@re...> - 2003-07-16 13:55:25
|
John Levon wrote: > On Tue, Jul 15, 2003 at 08:23:52PM -0400, Will Cohen wrote: > > >>fair enough, munmap implies msync. However, it still looks like there >>some kind of race condition causing zero length sample files. > > > There was one in earlier releases that caused an open by pp tools to > race against a daemon write ... The profiling was shutdown before the analysis was started, so that particular race wasn't being encountered. -Will |