Jeff Layton <jlayton@xxxxxxxxxxxxxxx> writes: > On Wed, 2016-08-03 at 11:23 -0500, Eric W. Biederman wrote: >> Nikolay Borisov <kernel@xxxxxxxx> writes: >> >> > >> > On busy container servers reading /proc/locks shows all the locks >> > created by all clients. This can cause large latency spikes. In my >> > case I observed lsof taking up to 5-10 seconds while processing >> > around >> > 50k locks. Fix this by limiting the locks shown only to those >> > created >> > in the same pidns as the one the proc fs was mounted in. When >> > reading >> > /proc/locks from the init_pid_ns proc instance then perform no >> > filtering >> >> If we are going to do this, this should be a recrusive belonging test >> (because pid namespaces are recursive). >> >> Right now the test looks like it will filter out child pid >> namespaces. >> >> Special casing the init_pid_ns should be an optimization not >> something >> that is necessary for correctness. (as it appears here). >> >> Eric >> >> > > Ok, thanks. I'm still not that namespace savvy -- so there's a > hierarchy of pid_namespaces? There is. > If so, then yeah does sound better. Is there an interface that allows > you to tell whether a pid is a descendant of a particular > pid_namespace? Yes. And each pid has an array of the pid namespaces it is in so it is a O(1) operation to see if that struct pid is in a pid namespace. Dumb question does anyone know the difference between fl_nspid and fl_pid off the top of your heads? I am looking at the code and I am confused why we have to both. I am afraid that there was some sloppiness when the pid namespace was implemented and this was the result. I remember that file locks were a rough spot during the conversion but I don't recall the details off the top of my head. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
