lkml.org 
[lkml]   [2006]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: pid_t range question
    From
    Date
    Jan Engelhardt <jengelh@linux01.gwdg.de> writes:

    >>> On Linux, type pid_t is defined as an int if you look
    >>> through all the intermediate definitions such as S32_T,
    >>> etc. However, it wraps at 32767, the next value being 300.
    >
    > There is also an aesthetical reason. If pids were allowed to exceed, say,
    > ten million, you would need a quite wide field in `ps` for the process
    > number which is on "normal desktop user" systems just require 5 or 6
    > decimal places. Well, what I mean, just look at this sample ps output:
    >
    > 17:59 shanghai:../fs/proc # ps
    > PID TTY TIME CMD
    > 1 - 00:00:00 init [3]
    > 4215914607 tty2 00:00:00 bash
    > 4215914653 tty2 00:00:00 ps
    >
    > mingw/msys and cygwin already have this "cosmetic problem" since windows
    > "pids" are usually above one million.

    Yes. Although this I'm not I'm not certain how bad the cosmetic problem
    is. Certainly significant enough that we don't want to change a good
    thing when we got it. But if there were real problems a big pid
    would solve I don't expect large pid numbers to stop us.

    >>> I know the
    >>> code "reserves" the first 300 pids.
    >
    > I cannot confirm that. When I start in "-b" mode and 'use' up all pids by
    > repeatedly executing /bin/noop, I someday get pids as low as 10
    > again, defined by how many kernel threads there are active before /bin/bash
    > started.

    Odd. When the search wraps it starts searching at 300.
    Still there are no locks around last_pid.

    >>I know for certain that proc assumes it can fit pid in
    >>the upper bits of an ino_t taking the low 16bits for itself
    >>so that may the entire reason for the limit.
    >>
    > inode number in /proc/XXX/fd creation currently is, IIRC
    > ino = (pid << 16) | fd
    > which limits both pid to 16 bits and the fdtable to 16 bits. See
    > fs/proc/inode-alloc.txt. At best, procfs should start using 64bit inode
    > numbers.

    Well it does use 64bit inode numbers but only on 64bit systems.
    Internally /proc doesn't care about the inode it is only for keep find
    and friends from getting confused.

    Figuring out how to use find_inode_number would likely be interesting,
    and a random inode allocation scheme would be interesting.

    Eric

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-02-09 19:15    [W:5.183 / U:0.596 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site