[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: slow bgp_delete

From: Vladimir Marek
Subject: Re: slow bgp_delete
Date: Wed, 20 May 2015 04:26:24 +0200
User-agent: Mutt/ (2013-10-16)

> > a) decreasing size of the 'bgpids' list. Why do we need 30k entries if
> > we don't trust that the IDs are unique? Maybe configuration or runtime
> > option?
> I've thought about it.  Posix only requires saving the statuses of the last
> CHILD_MAX asynchronous pids.  The bash code has traditionally saved
> the statues of the last `ulimit -u' processes, regardless of whether
> they're asynchronous.  I changed the bash development version to save
> only asynchronous jobs to the bgpids list about a month ago.

That might do the trick unless we are running tons of asynchronous

> > b) create hash map containing the IDs to decrease the search time. We
> > still need to maintain linked list to know which PID is oldest (to be
> > removed). The linked list might benefit from being double linked one
> > so that we are able to remove elements without traversing it again.
> http://lists.gnu.org/archive/html/bug-bash/2015-04/msg00075.html

Nice, clean patch. I like the idea to _not_ delete the PIDs from the
linked list if the PID is reused before we ran out of the circular
buffer. I would be concerned whether storing 1 million PIDs is not too
memory hungry though

> We'll see if the change to save only asynchronous pids makes enough of
> a difference.  I've attached that patch if you want to look at it; line
> numbers will certainly vary.

Thank you, I will try that.

> > c) some means to clear the 'bgpids' list during runtime.
> `wait' with no arguments discards all saved status values.
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/wait.html#tag_20_153
> `disown -a' will also work.

Ah, I missed that opportunity, good tip for a workaround.

Thank you Chet for your help

reply via email to

[Prev in Thread] Current Thread [Next in Thread]