Messages in this thread | | | Date | Wed, 13 Oct 1999 15:14:01 -0600 | From | Richard Gooch <> | Subject | Re: [patch] dynamic char and block devices |
| |
Jeff Garzik writes: > Richard Gooch wrote: > > > > Jeff Garzik writes: > > > The attached patch against 2.3.21 updates fs/devices.c to be dynamic, > > > instead of using two static arrays indexed by major number. > > > > Oh, my! So now we have a list search on every device open. > > Are you saying that blkdev_open/chrdev_open is a critical kernel > path that must be performance-optimized? I did not think so, but I > can always be wrong. :)
No, it's not that critical for most uses. But it is extending the path, which is generally a bad idea (I believe people often use the word "bloat" for that). And who knows if someone out there *is* doing open()s and close(s) rapidly for some special device?
> Since it looks doubtful that devfs will get applied anytime soon, do > you have an alternate solution to suggest?
No. Unless you store the fops with the inode, you don't have much choice but to do a table lookup. So far it hasn't hurt us because the lookup is an index operation, which is fast.
The mere fact that there is a table lookup required in the first place suggests to me that the basic design may be flawed. Obviously, in some cases lookups can't be avoided (for example finding the socket for an incoming IP packet), but devfs shows that there is a clean way to avoid that lookup. So the question must be asked: is the existing approach the best way?
Like I said, so far it hasn't hurt us, but your patch (reasonable in a devfs-less system with large majors) is increasing the penalty.
Regards,
Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |