Re: [PATCH v2 0/2] slightly rework memcg cache id determination

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 17, 2013 at 03:30:49PM +0200, Michal Hocko wrote:
> On Fri 14-06-13 14:04:34, Glauber Costa wrote:
> > Michal,
> > 
> > Let me know if this is more acceptable to you. I didn't take your suggestion of
> > having an id and idx functions, because I think this could potentially be even
> > more confusing: in the sense that people would need to wonder a bit what is the
> > difference between them.
> 
> Any clean up is better than nothing. I still think that split up and
> making the 2 functions explicit would be better but I do not think this
> is really that important. 
> 
Being all the same to you, I prefer like this. At least while the users are self
contained and live inside memcg core. This is because I believe having two functions
can be a bit confusing, and while not *totally* confusing, the array-like users
are relatively few.

 
> OK. If you had an _idx variant then you wouldn't need to add that
> VM_BUG_ON at every single place where you use it as an index and do not
> risk that future calls would forget about VM_BUG_ON.
> 
> > For the other cases, I have consolidated a bit the usage pattern around
> > memcg_cache_id.  Now the tests are all pretty standardized.
> 
> OK, Great!
>  
Thanks Michal! Please take a look at the individual patches if you can.

--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux