pcp
[Top] [All Lists]

[Bug 1229494] pmprintf shouldn't use /var/tmp files

To: pcp@xxxxxxxxxxx
Subject: [Bug 1229494] pmprintf shouldn't use /var/tmp files
From: bugzilla@xxxxxxxxxx
Date: Tue, 09 Jun 2015 01:03:50 +0000
Auto-submitted: auto-generated
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <bug-1229494-355098@xxxxxxxxxxxxxxxxxxx>
References: <bug-1229494-355098@xxxxxxxxxxxxxxxxxxx>
https://bugzilla.redhat.com/show_bug.cgi?id=1229494

Frank Ch. Eigler <fche@xxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |NEW
         Resolution|NOTABUG                     |---
           Keywords|                            |Reopened



--- Comment #2 from Frank Ch. Eigler <fche@xxxxxxxxxx> ---
(In reply to Nathan Scott from comment #1)
> There's no evidence of physical disk traffic presented here (an efficient
> filesystem should do none for this short-lived-file, to which libpcp issues
> buffered I/O only)

It does not take much thought to see why comment #0 true.  (Use of "buffered
I/O" at the glibc level is irrelevant.)  The libpcp code is opening files on
/var/tmp, which is normally a physical partition, not even a tmpfs.  It
creates, writes-to, and closes the file.  Later it opens, reads, closes, and
unlinks it.  A journaling filesystem can require physical & barriered I/O for
several of these operations.


% cat foo.c
#include <pcp/pmapi.h>
int main ()
{ 
  for(;;) {
    pmprintf("hello");
    pmflush();
  }
}
% gcc foo.c -lpcp
% ./a.out 2>/dev/null

iostat shows at least journaling-related traffic; more if sync(1)'s are going
in in the background.


> nor is there any evidence of "excess" syscalls being provided here.

Even one syscall is an excess over the apprx. zero needed for an in-memory
buffering.  strace -t -t -T:

20:58:24.154035 open("/var/tmp/pcp-KzKLEM", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
<0.
000023>
20:58:24.154067 umask(022)              = 0177 <0.000005>
20:58:24.154079 fcntl(3, F_GETFL)       = 0x8002 (flags O_RDWR|O_LARGEFILE)
<0.0
00005>
20:58:24.154091 fcntl(3, F_SETFL, O_RDWR|O_APPEND|O_LARGEFILE) = 0 <0.000005>
20:58:24.154104 lseek(3, 0, SEEK_END)   = 0 <0.000005>
20:58:24.154128 fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 <0.000005>
20:58:24.154142 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ab1c1db8000 <0.000006>
20:58:24.154158 write(3, "hello\n", 6)  = 6 <0.000009>
20:58:24.154175 lseek(3, 0, SEEK_SET)   = 0 <0.000005>
20:58:24.154187 read(3, "hello\n", 256) = 6 <0.000006>
20:58:24.154201 write(2, "hello\n", 6)  = 6 <0.000005>
20:58:24.154214 read(3, "", 256)        = 0 <0.000004>
20:58:24.154226 close(3)                = 0 <0.000006>
20:58:24.154239 munmap(0x2ab1c1db8000, 4096) = 0 <0.000007>
20:58:24.154254 unlink("/var/tmp/pcp-KzKLEM") = 0 <0.000013>
20:58:24.154277 umask(0177)             = 022 <0.000004>



> If you intend to "fix" this (non-problem) please provide both a tested patch

That is not a legitimate requirement for a bug report (or RFE).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=VknFAYqtzY&a=cc_unsubscribe

<Prev in Thread] Current Thread [Next in Thread>