On Thu, Jan 24, 2019 at 01:17:18AM -0500, Chris Down wrote: > memcg has a significant number of files exposed to kernfs where their > value is either exposed directly or is "max" in the case of > PAGE_COUNTER_MAX. > > There's a fair amount of duplicated code here, since each file involves > turning a seq_file to a css, getting the memcg from the css, safely > reading the counter value, and then doing the right thing depending on > whether the value is PAGE_COUNTER_MAX or not. > > This patch adds the macro DEFINE_MEMCG_MAX_OR_VAL, which defines and > implements a generic way to do this work, avoiding fragmenting logic. > > Signed-off-by: Chris Down <ch...@chrisdown.name> > Cc: Andrew Morton <a...@linux-foundation.org> > Cc: Johannes Weiner <han...@cmpxchg.org> > Cc: Tejun Heo <t...@kernel.org> > Cc: Roman Gushchin <g...@fb.com> > Cc: linux-kernel@vger.kernel.org > Cc: cgro...@vger.kernel.org > Cc: linux...@kvack.org > Cc: kernel-t...@fb.com > --- > mm/memcontrol.c | 78 ++++++++++++------------------------------------- > 1 file changed, 18 insertions(+), 60 deletions(-)
I think this increases complexity more than it saves LOC, unfortunately. The current situation is a bit repetitive, but much more obviously correct. And we're not planning on adding many more of those memcg interface files, so I this doesn't seem to be an improvement re: maintainability and future extensibility of the code.
