You are right - find_writeable_file is the common one, not find_readable_file (might make sense to reverse the ordering - readonly files at end instead of writeonly files at end - given find_readable_file is called less often). There are cases with a file opened many times from different processes that I have seen. Not sure why removing the ordering matters much - it is a possible, albeit usually slight, performance benefit to keep file handles we are most likely to want at the top of the list. On Mon, Oct 11, 2010 at 12:17 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Mon, 11 Oct 2010 12:04:09 -0500 > Steve French <smfrench@xxxxxxxxx> wrote: > >> find readable file is a common operation and the number of open files >> can be huge (thousands) >> > > I don't think so. It gets called from: > > get_cifs_acl > set_cifs_acl > > ...and those are only used when the cifsacl mount option is used, which > no one in their right mind does. > > Opening the same inode thousands of times is a pretty atypical > workload. Even if it isn't though, we still return as soon as we find > the first usable open file. > > But lets assume worst case -- we have some application that opens the > same inode thousands of times and none of them are usable. I'd still > argue that walking the entire list is a trivial amount of cpu time. > > Keeping a list ordered like this is fragile and easily broken. I think > we shouldn't rely on it here. > > -- > Jeff Layton <jlayton@xxxxxxxxxx> > -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
