CPU and paging question....

This is a discussion on CPU and paging question.... within the Linux Programming forums, part of the Platform Specific Boards category; I have a single 32 bit processor OpenBSD 4.1 box and a single 64 bit processor FreeBSD 5.1 box that ...

  1. #1
    Banned
    Join Date
    May 2007
    Location
    Berkeley, CA
    Posts
    329

    CPU and paging question....

    I have a single 32 bit processor OpenBSD 4.1 box and a single 64 bit processor FreeBSD 5.1 box that runs the exact same software on the 0x86.

    When I type the following line at the shell prompt

    Code:
    perl -e 'while (--$ARGV[0] and fork) {}; while () {}' 4
    The FreeBSD will slow down, but the OpenBSD doesn't. Any ideas why? Both boxes are running perl 5.8.8

  2. #2
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    Maybe OpenBSD has built in CPU quotas. It's meant to be a default secure OS.

  3. #3
    Banned
    Join Date
    May 2007
    Location
    Berkeley, CA
    Posts
    329
    I don't see any kind of cpu limits on either system.

    Here is the ouput from OpenBSD
    % ulimit -a
    -t: cpu time (seconds) unlimited
    -f: file size (blocks) unlimited
    -d: data seg size (kbytes) 524288
    -s: stack size (kbytes) 8192
    -c: core file size (blocks) unlimited
    -m: resident set size (kbytes) 465596
    -l: locked-in-memory size (kb) 156810
    -u: processes 24
    -n: file descriptors 128
    And here is the output from FreeBSD
    Code:
    % ulimit -a
    -t: cpu time (seconds)         unlimited
    -f: file size (blocks)         unlimited
    -d: data seg size (kbytes)     20000
    -s: stack size (kbytes)        7000
    -c: core file size (blocks)    0
    -m: resident set size (kbytes) 15000
    -l: locked-in-memory size (kb) 7000
    -u: processes                  20
    -n: file descriptors           90
    -N  9: socket buffer size (kb) unlimited
    -v: virtual memory size (kb)   unlimited

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Both systems only allow about 20 processes (24 and 20 respectively), so I expect your fork() calls are fairly limited.

    As to the "grinding to a halt", I expect the difference in behaviour is determined (at least partly) by the way that the fork() call works - but perhaps also the priority given to "new processes" by the kernel. I've heard before that fork() loops "kill" machines because the OS gives new processes a higher priority.

    The way fork works is that it either copies the entire process [this is "expensive"] or just copies the page-table such that the new pages are read-only, and then when a page is actually written to, it copies the page - this method is called "copy on write".

    There may be many other reasons why there is a difference.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21