Re: device struct bloat

On Tue, 2007-11-06 at 10:36 -0500, Alan Stern wrote:

Would it be possible to break at the second scan, that is the device
probe and stick that into a workqueue or something. Then we'd only ever
have driver->device nesting.

Alan and Oliver have done some work in this area I think, combined with
the suspend/bind/unbind issues. I'll let them comment on your patch :)

I gather the idea is to convert dev->sem to a mutex. This idea had
occurred to me a long time ago but I didn't pursue it because of the
sheer number of places where dev->sem gets used

That should never stop us from doing the right thing :-), also dev->sem
isn't used nearly as much as for example work_struct which was changed.

, not to mention the lockdep problems.

Right, that is the only sort-of valid reason this has not been done yet.

You can't possibly solve the lockdep problems here with a simple-minded
approach like your DRIVER_NORMAL, DRIVER_PARENT, etc. The device tree
is arbitrarily deep & wide, and there is at least one routine that
acquires the semaphores for _all_ the devices in the tree.

*blink* someone needs to take all locks - why?

This fact
alone seems to preclude using lockdep for device locks. (If there was
a form of mutex_lock() that bypassed the lockdep checks, you could use
it and avoid these issues.)

I'm sceptical of this, since its a simple tree (as opposed to a balanced
tree) a simple lock-coupling approach should be enough to guarantee
consistency.

Deadlock is a serious consideration. For the most part, routines
locking devices do so along a single path in the tree. For this simple
case the rule is: Never acquire a parent's lock while holding the
child's lock.

Sure, but once you have a parent's lock, you could unlock your
grandparent, no? (it having a locked child, your parent, should be
enough to guarantee its continued existence)

The routine that locks all the devices acquires the locks in order of
device registration. The idea here is that children are always
registered _after_ their parents, so this should be compatible with the
previous rule. But there is a potential problem: device_move() can
move an older child under a younger parent!

Seems like a weird rule, a typical tree locking rule would be to lock
them top-down - such a rule can easily cope with moves: lock old parent,
lock child, lock new parent, move child, unlock all in reverse order.

Right now we have no way to deal with this. There has been some
discussion of reordering the dpm_active list when a device is moved,
but so far nothing has been done about it.

Like said, I think the tree locking model should be revisited. A
top-down locking model with lock-coupling should, from my ignorant
perspective, solve your problems.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: How to populate a treeview from a dataset
    ... If it is then check to see if the parentId and child id of the ... 15 is a parent and a child of itself. ... And that same business is the headquarters for the purchasing group. ... 15 Null - root tree node, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How to populate a treeview from a dataset
    ... If it is then check to see if the parentId and child id of the ... 15 is a parent and a child of itself. ... And that same business is the headquarters for the purchasing group. ... 15 Null - root tree node, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: device struct bloat
    ... acquires the semaphores for _all_ the devices in the tree. ... lock in order to probe drivers for the child. ... parent again. ...
    (Linux-Kernel)
  • Re: Add Child Node to Treeview
    ... You cannot use the same value for strKey for multiple nodes. ... even though they refer to the same child. ... When I base the tree on this query I get ... 'Find the parent node and add it below that node's last child ...
    (microsoft.public.access.formscoding)
  • RE: [PATCH E 11/14] OMAP clock: track child clocks
    ... then disable the child, we will again walk up the tree, but since ... it will be a different clock tree. ... If we add in the parent handling, ...
    (Linux-Kernel)