Re: [Devel] Re: [RFC][PATCH 7/7] UBC: proc interface
From: Kir Kolyshkin
Date: Thu Aug 17 2006 - 12:11:46 EST
Greg KH wrote:
On Thu, Aug 17, 2006 at 05:43:16PM +0400, Kirill Korotaev wrote:I see two problems with that. But let me first describe the current
/proc/user_beancounters. This is how it looks like from inside a container:
On Wed, Aug 16, 2006 at 07:44:30PM +0400, Kirill Korotaev wrote:We can move it, if there are much objections.
Add proc interface (/proc/user_beancounters) allowing to see currentUgh, why /proc? This doesn't have anything to do with processes, just
state (usage/limits/fails for each UB). Implemented via seq files.
users, right? What's wrong with /sys/kernel/ instead?
I am objecting. /proc is for processes so do not add any new files
there that do not deal with processes.
Or /sys/kernel/debug/user_beancounters/ in debugfs as this is just adebugfs is usually OFF imho.
debugging thing, right?
No, distros enable it.
you don't export meminfo information in debugfs, correct?
That is because the meminfo is tied to processes, or was added to proc
before debugfs came about.
Then how about just /sys/kernel/ instead and use sysfs? Just remember,
one value per file please.
# cat /proc/user_beancounters
uid resource held maxheld barrier limit failcnt
123: kmemsize 836919 1005343 2752512 2936012 0
lockedpages 0 0 32 32 0
privvmpages 4587 7289 49152 53575 0
............(more lines like that).........................................
I.e. a container owner can take a glance over the current parameters,
their usage and (the thing that is really important) fail counters. Fail
counter increases each time a parameter hits the limit. This is very
straightforward way for container's owner to see if everything is OK or not.
So, the problems with /sys are:
(1) Gettng such info from 40+ files requires at least some script, while
now cat is just fine.
(2) Do we want to virtualize sysfs and enable /sys for every container?
Note that user_beancounters statistics is really needed for container's
owner to see. At the same time, container's owner should not be able to
modify it -- so we should end up with read/write ubc entries for the
host system and read-only ones for the container.
Taking into account those two issues, current /proc/user_beancounters
might be not that bad.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/