linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: Martin Mares <mj@ucw.cz>
Cc: Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] lockless, scalable get_pid(), for_each_process() elimination, 2.5.35-BK
Date: Thu, 19 Sep 2002 16:07:45 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.3.95.1020919155422.16070A-100000@chaos.analogic.com> (raw)
In-Reply-To: <20020919192758.GA430@ucw.cz>

On Thu, 19 Sep 2002, Martin Mares wrote:

> Hello, world!\n
> 
> > nevertheless we do lock up for 32 seconds if there are 32K PIDs allocated
> > in a row and last_pid hits that range - regardless of pid_max. (Depending
> > on the cache architecture it could take significantly more.)
> 
> What about randomizing the PID selection a bit? I.e., allocate PIDs
> consecutively as long as they are free; if you hit an already used
> PID, roll dice to find a new position where the search should be
> continued. As long as the allocated fraction of PID space is reasonably
> small, this algorithm should be very quick in average case.
> 
> Another possible solution: Divide PID space to blocks and for each
> block, keep a counter of PID's available in this block and when
> allocating, just skip blocks which are full. Runs in O(sqrt(PID space
> size)) in the worst case.
> 
> 				Have a nice fortnight

I remember something like the pid problem a few years ago when
somebody needed to get a unique 'key' value. The 'key' value was
used by a lock manager. It was not random, it just needed to be
unique, sort of like a pid. As I recall, the selection went something
like this:

(1)	When keys were given up (released), the key value was compared
with the last, lowest-key value given up. If this was lower, the last
lowest key-value was substituted.

(2)	When keys were allocated, the last lowest key-value was used.
Upon its use, the next available highest key-value was substituted.

(3)	Somehow, I don't remember the alogrithm, the highest key-
value became the lowest key-value when all the higher keys were
released. At this time, everything was free.

Nobody ever had to scan anything to get the next-available key.
So what was saved in memory was, the highest key-value allocated, and
the lowest key-value allocated.

Anybody here work on the Cluster Lock Manager for DEC?  That's what
used the keys.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.


  parent reply	other threads:[~2002-09-19 19:59 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-17 23:06 [patch] lockless, scalable get_pid(), for_each_process() elimination, 2.5.35-BK Ingo Molnar
2002-09-18  0:22 ` William Lee Irwin III
2002-09-18  1:27   ` David S. Miller
2002-09-18  2:22     ` William Lee Irwin III
2002-09-18 10:11   ` Ingo Molnar
2002-09-18 14:28     ` William Lee Irwin III
2002-09-18 12:32 ` Andries Brouwer
2002-09-18 12:56   ` Ingo Molnar
2002-09-18 16:17     ` Linus Torvalds
2002-09-18 16:46       ` Ingo Molnar
2002-09-18 16:57       ` Ingo Molnar
2002-09-18 18:28     ` Andries Brouwer
2002-09-18 18:27       ` William Lee Irwin III
2002-09-18 19:00       ` Ingo Molnar
2002-09-18 20:11         ` Andries Brouwer
2002-09-18 20:29           ` William Lee Irwin III
2002-09-18 21:15             ` Andries Brouwer
2002-09-19  3:05               ` Ingo Molnar
2002-09-19 13:11                 ` Andries Brouwer
2002-09-21 12:56                   ` quadratic behaviour Andries Brouwer
2002-09-21 17:06                     ` Linus Torvalds
2002-09-21 17:35                       ` William Lee Irwin III
2002-09-21 17:49                       ` Ingo Molnar
2002-09-21 17:46                         ` William Lee Irwin III
2002-09-18 14:49   ` [patch] lockless, scalable get_pid(), for_each_process() elimination, 2.5.35-BK William Lee Irwin III
2002-09-18 15:01     ` Cort Dougan
2002-09-18 15:33       ` Ingo Molnar
2002-09-18 15:31         ` yodaiken
2002-09-18 15:35         ` Cort Dougan
2002-09-18 15:37       ` Rik van Riel
2002-09-18 15:50       ` Alan Cox
2002-09-18 18:31     ` Andries Brouwer
2002-09-18 18:32       ` William Lee Irwin III
2002-09-18 16:15   ` Linus Torvalds
2002-09-18 16:32     ` Rik van Riel
2002-09-18 16:48       ` Linus Torvalds
2002-09-18 17:31         ` Ingo Molnar
2002-09-18 21:46         ` Rogier Wolff
2002-09-18 16:41     ` Ingo Molnar
2002-09-18 16:45       ` William Lee Irwin III
2002-09-18 16:59         ` Linus Torvalds
2002-09-18 17:36         ` Ingo Molnar
2002-09-18 17:36           ` William Lee Irwin III
2002-09-18 17:46             ` Linus Torvalds
2002-09-18 17:47               ` William Lee Irwin III
2002-09-18 17:59             ` Ingo Molnar
2002-09-18 17:50               ` William Lee Irwin III
2002-09-18 18:07                 ` Ingo Molnar
2002-09-19 19:27           ` Martin Mares
2002-09-17 15:31             ` Pavel Machek
2002-09-19 20:07             ` Richard B. Johnson [this message]
2002-09-18 16:46     ` Rik van Riel
2002-09-18 16:53       ` Linus Torvalds
2002-09-18 17:00         ` Rik van Riel
2002-09-18 17:16           ` Linus Torvalds
2002-09-18 17:28             ` Ingo Molnar
2002-09-18 17:38           ` Ingo Molnar
2002-09-18 17:24         ` Ingo Molnar
2002-09-18 17:30           ` Linus Torvalds
2002-09-18 17:35             ` Cort Dougan
2002-09-18 17:43               ` Rik van Riel
2002-09-18 17:48               ` Martin J. Bligh
2002-09-18 17:57                 ` Cort Dougan
2002-09-18 18:08                   ` Martin J. Bligh
2002-09-18 18:28                     ` Ingo Molnar
2002-09-18 18:33                       ` Linus Torvalds
2002-09-18 18:51                         ` Ingo Molnar
2002-09-18 18:56                           ` interruptible_sleep_on_timeout() and signals Imran Badr
2002-09-19  7:16                             ` David Woodhouse
2002-09-18 19:53                       ` [patch] lockless, scalable get_pid(), for_each_process() elimination, 2.5.35-BK Martin J. Bligh
2002-09-22  0:34                   ` Andrea Arcangeli
2002-09-22 10:02                     ` Ingo Molnar
2002-09-22 15:27                       ` Andrea Arcangeli
2002-09-18 18:02               ` Ingo Molnar
2002-09-18 17:58                 ` Cort Dougan
2002-09-18 18:14                   ` Ingo Molnar
2002-09-18 17:54             ` Alan Cox
2002-09-18 17:54             ` Ingo Molnar
2002-09-18 18:00               ` yodaiken
2002-09-18 18:21                 ` Ingo Molnar
2002-09-18 18:33                   ` yodaiken
2002-09-18 16:55     ` Alan Cox

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=Pine.LNX.3.95.1020919155422.16070A-100000@chaos.analogic.com \
    --to=root@chaos.analogic.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mj@ucw.cz \
    /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;
as well as URLs for NNTP newsgroup(s).