On Thu, 17 May 2012, Glauber Costa wrote: > On 05/16/2012 06:31 PM, Christoph Lameter wrote: > > > There are a couple of places where that test seems to be okay (I remember > > > 1 in > > > > the slub), but at least for the "FULL" test here, we should be > > > testing>= > > > > FULL. > > > > > > > > Also, I don't like the name FULL too much, since I do intend to add a > > > new one > > > > soon (MEMCG, as you can see in my series) > > Ok. Why would memcg need an additional state? > > Please refer to my patchset for the full story. > I add state both to the slab and to the slub for that. > > But in summary, it is not unlike the "SYSFS" state: we depend on something > else outside of the slab domain to be ready before we can proceed. > > Specifically, we need to register each cache with an index. And for that, we > use idr/ida. When it is ready, we run code to register indexes for all caches > that are already available. After that, we just grab an index right away - > much like sysfs state for aliases. Why can this processing not be done when sysfs has just been initialized? > > > > Since we are using slab-specific states like PARTIAL_L3 here, maybe we > > > can use > > > > slub's like SYSFS here with no problem. > > Sure. I thought there would only be special states before UP. > > > > > > If we stick to>= and<= whenever needed, that should reflect a lot > > > better > > > > what the algorithm is really doing > > How so? > > In the sense that we very rarely want to do some action *at a specific > moment*. Most of the time we want to separate the world into before and after > a state. We test == instead of <= and >=, and it happens to work because of > the specific order of things, which are subject to change in a rework or > another... The reason to use == is because we want things to happen only at a particular stage of things. The == SYSFS means we will only do an action if the slab system is fully functional. Such things will have to be reevaluated if the number of states change. -- 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>