Quoting Li Zefan (lizf@xxxxxxxxxxxxxx):
> While I was doing testing by open/close files like this:
> for (i = 0; i < LOOP; i++) {
> fd = open("/dev/null");
> close(fd);
> }
> It got a bit slower when devcg is used, so I made this patch
> to speed it up.
>
> But walking through whitelist in devcgroup_inode_permission()
> doesn't seem to be a hot-path, if so this patch probably doesn't
> worth it, and it may not work well under real workload.
>
> Just post it to see if someone thinks it's useful.
Well there is a tendency of some software to repeatedly try to
open the same device - for instance sendmail opens /dev/null a
few times during startup. But I don't think 4-6 times during startup
justifies a hack like this.
OTOH I didn't expect the lookup to stay a linear linked list walk for
this long :) I'd be interested to hear the typical size of a whitelist
in your or openvz's experience, so we could see if a hash fn or some
other speedup makes sense. We also could consider taking a few entries
- like /dev/{u,}random, /dev/null, /dev/console, and /dev/zero, and
taking them out of the loop.
How much of a slow-down were you seeing in your loop, and how many
whitelist entries did you have?
-serge
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
