public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Davy Durham <ddurham@davyandbeth.com>
To: linux-kernel@vger.kernel.org
Subject: PID_MAX_LIMIT limit on ia32?
Date: Wed, 24 Nov 2010 14:22:37 -0600	[thread overview]
Message-ID: <1290630157.14831.226.camel@ubuntu> (raw)

I have searched around without a definitive answer to my question.

PID_MAX_LIMIT is currently defined as:

        /*
         * A maximum of 4 million PIDs should be enough for a while.
         * [NOTE: PID/TIDs are limited to 2^29 ~= 500+ million, see
futex.h.]
         */
        #define PID_MAX_LIMIT (CONFIG_BASE_SMALL ? PAGE_SIZE * 8 :
(sizeof(long) > 4 ? 4 * 1024 * 1024 : PID_MAX_DEFAULT))
        

And PID_MAX_DEFAULT is normally 32k.

I found a comment on the net:

        “When recycling PID numbers, the kernel must manage a
        pidmap_array bitmap that denotes which are the PIDs currently
        assigned and which are the free ones. Because a page frame
        contains 32,768 bits, in 32-bit architectures the pidmap_array
        bitmap is stored in a single page. In 64-bit architectures,
        however, additional pages can be added to the bitmap when the
        kernel assigns a PID number too large for the current bitmap
        size. These pages are never released.”


Which may seem to indicate that PID_MAX_DEFAULT cannot be more than 1
memory page on 32bit archs.

Can the PID_MAX_LIMIT #define be increased safely on the ia32 arch which
would cause pidmap_array to use more than one memory page?  (say 4 pages
or so).

I thought about just compiling it and testing things, but was unsure if
I would run into problems long-term.

[Please CC me on the response as I'm not currently subscribed]

TIA,
  Davy


                 reply	other threads:[~2010-11-24 20:22 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1290630157.14831.226.camel@ubuntu \
    --to=ddurham@davyandbeth.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox