On Fri, 07 Nov 2008 07:51:32 -0800 ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote: > >> and where this is at least partially > >> a bug fix I would rather not have the change depend on enhancing > >> the VFS. > >> > >> The algorithm is actually very aggressive and in practice you don't > >> see any /proc/<pid>/net showing up as a mount point. > > > > Do you think it has failure modes? Most particularly: obscure usage > > patterns which can cause memory exhaustion? > > I don't think we can pin anything that way that we can't > pin right now. > > You might be able to pin more if you happen to mount something > on top of /proc/<pid>/net/ but that is an unprivileged operation. I was thinking more along the lines of some repeated operation which generates reclaimable storage, only nothing reclaims that storage sufficiently promptly (the 500 second delay, perhaps). Like the problem we had with SLAB_DESTROY_BY_RCU and, umm, I think it was route cache entries increasing like mad and not getting reaped. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
