need for another mutex type/flag?
deischen at freebsd.org
Tue Jan 27 11:46:16 PST 2009
On Tue, 27 Jan 2009, Julian Elischer wrote:
> Robert Watson wrote:
>> On Sun, 25 Jan 2009, Julian Elischer wrote:
>>> Even purely documentary would be good but given the option, I'd like it to
>>> scream when Witness is enabled and you try get another mutex....
>>> there are certain contexts (e.g. in most netgraph nodes) where we really
>>> want the authors to only take such locks and taking more unpredictable
>>> mutexes plays havoc with netgraph response times as a system as a whole,
>>> since if one node blocks, teh thread doesn't get to go off and service
>>> other nodes.
>> I thought lots of Netgraph nodes liked to do things like call m_pullup()
>> and m_prepend()? Disallowing acquiring mutexes will prevent them from
>> doing that.
> I think I mentioned that in another mail.
> The problem I see is that some module writers are tempted to
> just use a mutex in their node without thinking about what the
> result will be. My understanding is that the mbuf allocation
> code has been tuned to within an inch of its life to try
> keep it's waits to a minimum. I am worried about it,
> but I am more worried about a netgraph node waiting on something
> that is depending on some piece of hardware such as what I think
> HPS had in his suggested patch for the bluetooth code..
I thought all you wanted to mandate that the netgraph code
itself didn't nest any mutexes. If it doesn't hold any of
its own mutexes while calling m_prepend(), etc, then is
that still a problem?
More information about the freebsd-arch