1. Wez Furlong
  2. atomicparsley
  3. Issues
Issue #27 open

high cpu on freeBSD

Anonymous created an issue

I compiled the latest verson on freebsd 8.3 p1 2 weeks or so ago. I noticed the cpu gets VERY high (like 97%) when I call the bin. Anyone else come across this?

It's on a shared hosted env. and I'm not root. If I remember right I had to comment out some CD related things - no cd player installed.

Comments (9)

  1. Wez Furlong repo owner

    Honestly, it's very difficult to even begin to help you out here; sounds like you hacked some code out and now "it doesn't work".

    If you can provide more details on what you did, how you're running it and so on we might have a chance to help, but without that, we'll just have to close this report as invalid.

    Since you reported anonymously, I'm not even sure you'll receive this note. Don't take it personally!

  2. Anonymous

    It does work, just consumes LOADS of CPU. My initial message WAS lacking in detail. Not taken personally.

    I've been using your AP on cygwin with no problems for quite a time - well since the strcpy / memcpy thing was changed start last year (or 2010? - my bad memory) it's been very stable. This though is my 1st make on real *nix.

    Z:\src\wez-atomicparsley-5191bfa76f21 - from a few weeks ago. autogen and configure worked fine as I recall, but I made these changes to get make to make (!) _________

    FILE: CDtoc.cpp WAS:

    #if defined (DARWIN_PLATFORM)
    	uint8_t LEADOUT_TRACK_NUMBER = MACOSX_LEADOUT_TRACK;
    #elif defined (HAVE_LINUX_CDROM_H)
    	uint8_t LEADOUT_TRACK_NUMBER = CDROM_LEADOUT;
    #elif defined (_WIN32)
    	uint8_t LEADOUT_TRACK_NUMBER = 0xAA; //NOTE: for WinXP IOCTL_CDROM_READ_TOC_EX code, its 0xA2
    #endif
    

    -------------------------------------------

    BECAME:

    #if defined (DARWIN_PLATFORM)
    	uint8_t LEADOUT_TRACK_NUMBER = MACOSX_LEADOUT_TRACK;
    #elif defined (HAVE_LINUX_CDROM_H)
    	uint8_t LEADOUT_TRACK_NUMBER = CDROM_LEADOUT;
    #elif defined (_WIN32)
    	uint8_t LEADOUT_TRACK_NUMBER = 0xAA; //NOTE: for WinXP IOCTL_CDROM_READ_TOC_EX code, its 0xA2
    #else 
    	uint8_t LEADOUT_TRACK_NUMBER = 0xAA; 
    #endif
    

    _________

    OTHERWISE uint8_t LEADOUT_TRACK_NUMBER was not defined.

    _________

    FILE: util.h WAS:

    #if !defined(HAVE_LROUNDF)
    int lroundf(float a);
    #endif
    

    -------------------------------------------

    BECAME:

    #if !defined(HAVE_LROUNDF)
    //int lroundf(float a);
    #endif
    

    _________

    FILE: util.cpp WAS:

    #if !defined(HAVE_LROUNDF)
    int lroundf(float a) {
    	return (int)(a/1);
    }
    #endif
    

    -------------------------------------------

    BECAME:

    #if !defined(HAVE_LROUNDF)
    //int lroundf(float a) {
    //	return (int)(a/1);
    //}
    #endif
    

    _________

    This because, as I recall, double definition of lroundf

    Those are the ONLY changes made AFAICT - doing a diff.

    Afterwards AP compiled

    Hope this info helps

  3. Wez Furlong repo owner

    Does the same file and run take the same amount of CPU when you run it on Windows instead?

    When running it on fbsd, can you perform some "monte carlo" debugging; every couple of seconds run "gstack `pgrep AtomicParsley` >> ap.txt" and attach that output to this ticket. Would be good to get about a dozen or so of those spread out over about 30 seconds or so. Doesn't need to be precise.

    Make sure that you have debugging enabled in the build for this to be the most effective.

    Also: please run "hg diff" and attach that output to this ticket so that I can more clearly see the code changes (it's easier to read that way).

  4. Will Elwood

    I don't know if this project is still being maintained considering the lack of activity, but just in case it is... I hit this issue too, bisected to the specific commit where performance on FreeBSD falls off a cliff and guessed the specific lines of code in the commit responsible. For the record my experience with both C and FreeBSD is quite limited, but since my perseverance here seems to have yielded results I've cleaned up the necessary fixes to apply to tip in a pull request. Below is a summary of my findings.

    Firstly, my test setup:

    $ uname -mrs
    FreeBSD 9.3-RELEASE-p31 amd64
    $ # Technically it's a standard jail in a `FreeNAS-9.3-STABLE-201601181840` host.
    $ autoconf --version | head -n 1
    autoconf (GNU Autoconf) 2.69
    $ gmake --version | head -n 1
    GNU Make 4.1
    $ g++ --version | head -n 1
    g++ (GCC) 4.2.1 20070831 patched [FreeBSD]
    $ stat -f '%z' ../../test.mp4
    1060966245
    

    Last commit before issue appears: c7d7235

    $ hg up -C c7d7235
    [snip]
    $ hg purge --all
    $ hg import --no-commit --verbose -- "../atomicparsley-1758d64-freebsd.patch"
    [snip]
    $ autoconf
    $ autoheader
    $ ./configure
    [snip]
    $ gmake
    [snip]
    $ time ./AtomicParsley ../../test.mp4 --freefree --overWrite --artwork REMOVE_ALL
    
     Started writing to temp file.
     Progress: =======================================================>100%|
     Finished writing to temp file.
            1.96 real         0.27 user         1.66 sys
    

    First commit with issue: 1758d64

    $ hg up -C 1758d64
    [snip]
    $ hg purge --all
    $ hg import --no-commit --verbose -- "../atomicparsley-1758d64-freebsd.patch"
    [snip]
    $ autoconf
    $ autoheader
    $ ./configure
    [snip]
    $ gmake
    [snip]
    $ time ./AtomicParsley ../../test.mp4 --freefree --overWrite --artwork REMOVE_ALL
    
     Started writing to temp file.
     Progress: ====================================================>95%----|
     Finished writing to temp file.
         2845.53 real       171.35 user      2673.22 sys
    

    Stack:

    There is no gstack or pgrep on FreeBSD, so I have used pstack - I have no idea if the output is remotely similar. Every single time I took a reading, the output was the same.

    $ pstack -v -O $PID
    pstack: object loaded: /hg/atomicparsley/AtomicParsley @ 0
    pstack: object loaded: /lib/libz.so.6 @ 34368450560
    pstack: object loaded: /usr/lib/libstdc++.so.6 @ 34370629632
    pstack: object loaded: /lib/libm.so.5 @ 34373804032
    pstack: object loaded: /lib/libgcc_s.so.1 @ 34376036352
    pstack: object loaded: /lib/libc.so.7 @ 34378190848
    pstack: object loaded: /usr/lib/libsupc++.so.1 @ 34381709312
    pstack: object loaded: /libexec/ld-elf.so.1 @ 34366246912
    26536: /hg/atomicparsley/AtomicParsley
    ----------------- thread -1 (running) -----------------
     0x8012a312c 0x8014f1a60 __sys_read (0, 0, 30006, 0, 14f1ad7, 8) + c in /lib/libc.so.7
    

    Observations:

    • CPU usage immediately jumps to 100% (1 core) and remains there until completion.
    • Progress stays still for several minutes and then makes a large jump (eg. I was watching it at 18% for ~3 minutes before it jumped to 24%).
    • Size of temp file makes similar jumps in step with the progress bar (eg. the 18% to 24% jump resulted in the file size changing from 182MiB to 242MiB).
    • The entire source file is being read from RAM using the ZFS ARC cache, no significant read activity on any physical disks.
    • The entire temp file appears to be being written to RAM using the ZFS ARC cache as well, no significant write activity on any physical disks until 100%. At 100% there is a significant burst of write activity on the physical disks.

    After applying fix:

    $ hg up -C 1758d64
    [snip]
    $ hg purge --all
    $ hg import --no-commit --verbose -- "../atomicparsley-1758d64-freebsd.patch"
    $ hg import --no-commit --verbose -- "../atomicparsley-1758d64-cpudiet.patch"
    [snip]
    $ autoconf
    $ autoheader
    $ ./configure
    [snip]
    $ gmake
    [snip]
    $ time ./AtomicParsley ../../test.mp4 --freefree --overWrite --artwork REMOVE_ALL
    
     Started writing to temp file.
     Progress: ====================================================>95%----|
     Finished writing to temp file.
            1.83 real         0.33 user         1.50 sys
    
  5. Log in to comment