Hello Glauber, On Mon, Oct 17, 2011 at 1:56 AM, Glauber Costa <glommer@xxxxxxxxxxxxx> wrote: > On 10/15/2011 04:38 AM, Suleiman Souhlal wrote: > 3) Easier to do per-cache tuning if we ever want to. What kind of tuning are you thinking about? > About, on-demand creation, I think it is a nice idea. But it may impact > allocation latency on caches that we are sure to be used, like the dentry > cache. So that gives us: I don't think this is really a problem, as only the first allocation of that type is impacted. But if it turns out it is, we can just always create them asynchronously (which we already do if we have GFP_NOWAIT). >> +When a kmem_cache gets migrated to the root cgroup, "dead" is appended to >> +its name, to indicated that it is not going to be used for new >> allocations. > > Why not just remove it? Because there are still objects allocated from it. > * We still need the ability to restrict kernel memory usage separately from > user memory, dependent on a selectable, as we already discussed here. This should not be difficult to add. My main concern is when and what to reclaim, when there is a kernel memory limit. Thanks for the comments, -- Suleiman -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>