Ed,
Thanks :) I'll be implementing this as discussed over the next few
months thanks for the technical detail I've been extremely busy with
finals. I will write the list with my thoughts within the next week,
sorry for the delay.
=jt
On May 8, 2009, at 17:41, Ed Schouten <e...@80386.nl> wrote:
Hi,
* vasanth raonaik <vasanth.raon...@gmail.com> wrote:
Hello Jt,
I am a newbee in this alias. I am having a very basic question. It
would be
really good if you could give me some of this information.
Could you please elaborate on what is the current architecture of
sysctl
implementation and How the concurrency would benefit us.
Right now sysctl is synchronized using the sysctl lock. The problem is
that certain sysctls just block for a very long time (especially
some of
the GEOM ones). We also call sysctl when we execute new processes, to
obtain a random number for the stack protector. This means we have
quite
a lot of contention on it. This lock needs to be there, because
sysctls
can be added and removed on demand.
I think I discussed this with John Baldwin (right?) and I think we
also
have the issue that we cannot allow an unbounded amount of concurrent
calls to sysctl, because sysctl wires memory.
A solution would be to solve it as follows:
- Use a semaphore, initialized to some insane high value to put an
upper
limit on the amount of concurrent sysctl calls. I'm not sure whether
this is really needed. Maybe this issue is not as serious as we think
it is.
- Use an rw/rm/sxlock to protect the sysctl tree, but only pick up
the lock when we traverse parts of the sysctl tree that has
dynamically created entries.
--
Ed Schouten <e...@80386.nl>
WWW: http://80386.nl/
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
