On Mon, Oct 12, 2015 at 01:49:59PM -0400, Dave Goel wrote:
>
> OTOH, I guess if one has to write cleaner/other meta scripts without
> proper traps, the cleaner can simply check if linux's PID counter
> is too close to the current PID, and if so, refrain from drastic
> actions. For the latter, I wo
Ted,
Thanks for your patience with me.
I thought I had this down, and I thought that the only real
problem is *immediate* re-use and the race conditions it causes
and that for all other cases, scripts can find a way to work
around things. But:
But truly, your example stumps me atm.
Completely u
On Sun, Oct 11, 2015 at 01:44:02PM -0400, Dave Goel wrote:
>
> Here's a method to achieve the same goal (no immediate pid re-use),
> but without using any queues whatsoever:
>
> All freshly available PIDs are entered into PoolA.
>
> Every N seconds, a timer moves PoolA->PoolB, and PoolB->Free PI
Ted,
Here's a method to achieve the same goal (no immediate pid re-use),
but without using any queues whatsoever:
All freshly available PIDs are entered into PoolA.
Every N seconds, a timer moves PoolA->PoolB, and PoolB->Free PIDs.
And, the current PID allocation algo continues its allocation j
Hi Ted,
Thanks for responding. Fair points all of them.
I would like to take exception to one of them, the bottleneck part:
> The biggest problem is that accessing this free pid queue is now
> a locking bottleneck --- especially on a very large NUMA system
That was exactly what I was trying to
On Fri, Oct 09, 2015 at 10:00:34PM -0400, Dave Goel wrote:
>
> All that the entire system needs is one queue of free PIDs. Any time you
> need a PID, take it from the head. Any time a PID is newly freed, push it at
> the back of the queue. That's it! The overhead seems minimal to me.
>
> The que
> On Oct 10, 2015, at 10:00, Dave Goel wrote:
>
> Pardon the subject line! I think the PID algo. is actually pretty
> good and cheap.
>
>
> I just think that a very minor tweak could actually make it *actually* do
> what it always intended to do (that is, satisfy the PID-AIM listed below)!
>
Pardon the subject line! I think the PID algo. is actually pretty
good and cheap.
I just think that a very minor tweak could actually make it *actually* do
what it always intended to do (that is, satisfy the PID-AIM listed below)!
No expanded PID renumbering, no incompatibility introduction, not
8 matches
Mail list logo
