[Apologies for over-the-head reply]
> Keith Owens wrote:
> > 1) Do the reference counting outside the module, before it is entered.
> >
> > This is why Al Viro added the owner: __THIS_MODULE; line to various
> > structures. The problem is that it spreads like a cancer. Every
> > structure that contains function pointers needs an owner field.
> > Every bit of code that dereferences a function pointer must first
> > bump the owner's use count (using atomic ops) and must cope with the
> > owner no longer existing.
a) How many place of that kind do we have?
b) How many structures have 'owner' field? How many instances of these
structures exist and how large each of them is?
> > Not only does this pollute all structures that contain function
> > pointers, it introduces overhead on every function dereference. All
Not true. As the matter of fact, for all such structures we have
activation points - open/mount/exec/etc. All subsequent uses are
protected by that - e.g. if ->write() is called outside of ->open()/->release()
range we are fucked regardless of modules, since ->write() can refer to the
structures created by ->open() and torn down by ->release().
I would really like to see hard data - either from you or from
Rusty - regarding the overhead you are talking about. As it is, the
only major class of structures that have ->owner is file_operations
of character devices. Everything else is red herring - too few instances
to talk about (e.g. each binfmt type compiled into the kernel wastes a
word - all 4 or 5 of them).
And with file_operations we are talking about a word in a structure
that currently consists of 18 words. And has 200-300 instances in the
kernel with every filesystem and every driver compiled in. In real-world
cases you'll have ~40 of these. Pardon me when I don't take the talks about
overhead seriously in this case. Especially since your quiescense code will
take more than a kilobyte.
Folks, how about you give some numbers - "spreads like a cancer"
would be great on a talk show, but I'd expect something better on l-k...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 07 2002 - 22:00:10 EST