On Wed, Oct 28, 2009 at 12:50:14PM +0530, Balbir Singh wrote: > * menage@xxxxxxxxxx <menage@xxxxxxxxxx> [2009-10-27 23:06:19]: > > > On Tue, Oct 27, 2009 at 11:04 PM, Paul Menage <menage@xxxxxxxxxx> wrote: > > > On Tue, Oct 27, 2009 at 6:04 PM, Li Zefan <lizf@xxxxxxxxxxxxxx> wrote: > > >> > > >> I think maybe it's better to store struct file *file to struct cftype, > > >> so we don't need to change write_string(), write(), write_u64() > > >> and write_s64(). > > > > > > We can't do that - multiple open files could be using the same cftype > > > at the same time. I'd be inclined if necessary to just pass the struct > > > file* in, rather than risk needing to change it to pass more > > > parameters later. > > > > And I imagine that the number of handlers that actually make use of > > the cftype* is rather small. If we pass the file* to the handler > > instead of passing the cftype*, and provide an inline function to get > > from the file* to the cftype*, then we can avoid adding an extra > > parameter to the handlers. > > > > This sounds like a reasonable approach except for the cost of > indirection (which I assume is acceptable). Suprisingly few places require the struct cftype *. So they don't pay any additional cost. Note that the code in kernel/cgroup.c always fetches the op pointer by fetching and dereferencing the struct cftype *. So fetching it with an inline shouldn't add much to the data cache footprint. The minisclue savings come in two places where struct file * was already passed. Cheers, -Matt Helsley _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
