From: "Paul Menage" <menage@google.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"balbir@linux.vnet.ibm.com" <balbir@linux.vnet.ibm.com>,
"xemul@openvz.org" <xemul@openvz.org>,
"lizf@cn.fujitsu.com" <lizf@cn.fujitsu.com>,
"yamamoto@valinux.co.jp" <yamamoto@valinux.co.jp>
Subject: Re: [RFC][PATCH 2/3] memcg:: seq_ops support for cgroup
Date: Tue, 20 May 2008 11:46:46 -0700 [thread overview]
Message-ID: <6599ad830805201146g5a2a8928l6a2f5adc51b15f15@mail.gmail.com> (raw)
In-Reply-To: <20080520180841.f292beef.kamezawa.hiroyu@jp.fujitsu.com>
On Tue, May 20, 2008 at 2:08 AM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
> Does anyone have a better idea ?
As a way of printing plain text files, it seems fine.
My concern is that it means that cgroups no longer has any idea about
the typing of the data being returned, which will make it harder to
integrate with a binary stats API. You'd end up having to have a
separate reporting method for the same data to use it. That's why the
"read_map" function specifically doesn't take a seq_file, but instead
takes a key/value callback abstraction, which currently maps into a
seq_file. For the binary stats API, we can use the same reporting
functions, and just map into the binary API output.
Maybe we can somehow combine the read_map() abstraction with the
seq_file's start/stop/next operations.
Paul
> ==
>
> Currently, cgroup's seq_file interface just supports single_open.
> This patch allows arbitrary seq_ops if passed.
>
> For example, "status per cpu, status per node" can be very big
> in general and they tend to use its own start/next/stop ops.
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
>
> ---
> include/linux/cgroup.h | 9 +++++++++
> kernel/cgroup.c | 32 +++++++++++++++++++++++++++++---
> 2 files changed, 38 insertions(+), 3 deletions(-)
>
> Index: mm-2.6.26-rc2-mm1/include/linux/cgroup.h
> ===================================================================
> --- mm-2.6.26-rc2-mm1.orig/include/linux/cgroup.h
> +++ mm-2.6.26-rc2-mm1/include/linux/cgroup.h
> @@ -232,6 +232,11 @@ struct cftype {
> */
> int (*read_seq_string) (struct cgroup *cont, struct cftype *cft,
> struct seq_file *m);
> + /*
> + * If this is not NULL, read ops will use this instead of
> + * single_open(). Useful for showing very large data.
> + */
> + struct seq_operations *seq_ops;
>
> ssize_t (*write) (struct cgroup *cgrp, struct cftype *cft,
> struct file *file,
> @@ -285,6 +290,10 @@ int cgroup_path(const struct cgroup *cgr
>
> int cgroup_task_count(const struct cgroup *cgrp);
>
> +
> +struct cgroup *cgroup_of_seqfile(struct seq_file *m);
> +struct cftype *cftype_of_seqfile(struct seq_file *m);
> +
> /* Return true if the cgroup is a descendant of the current cgroup */
> int cgroup_is_descendant(const struct cgroup *cgrp);
>
> Index: mm-2.6.26-rc2-mm1/kernel/cgroup.c
> ===================================================================
> --- mm-2.6.26-rc2-mm1.orig/kernel/cgroup.c
> +++ mm-2.6.26-rc2-mm1/kernel/cgroup.c
> @@ -1540,6 +1540,16 @@ struct cgroup_seqfile_state {
> struct cgroup *cgroup;
> };
>
> +struct cgroup *cgroup_of_seqfile(struct seq_file *m)
> +{
> + return ((struct cgroup_seqfile_state *)m->private)->cgroup;
> +}
> +
> +struct cftype *cftype_of_seqfile(struct seq_file *m)
> +{
> + return ((struct cgroup_seqfile_state *)m->private)->cft;
> +}
> +
> static int cgroup_map_add(struct cgroup_map_cb *cb, const char *key, u64 value)
> {
> struct seq_file *sf = cb->state;
> @@ -1563,8 +1573,14 @@ static int cgroup_seqfile_show(struct se
> static int cgroup_seqfile_release(struct inode *inode, struct file *file)
> {
> struct seq_file *seq = file->private_data;
> + struct cgroup_seqfile_state *state = seq->private;
> + struct cftype *cft = state->cft;
> +
> kfree(seq->private);
> - return single_release(inode, file);
> + if (!cft->seq_ops)
> + return single_release(inode, file);
> + else
> + return seq_release(inode, file);
> }
>
> static struct file_operations cgroup_seqfile_operations = {
> @@ -1585,7 +1601,7 @@ static int cgroup_file_open(struct inode
> cft = __d_cft(file->f_dentry);
> if (!cft)
> return -ENODEV;
> - if (cft->read_map || cft->read_seq_string) {
> + if (cft->read_map || cft->read_seq_string || cft->seq_ops) {
> struct cgroup_seqfile_state *state =
> kzalloc(sizeof(*state), GFP_USER);
> if (!state)
> @@ -1593,7 +1609,17 @@ static int cgroup_file_open(struct inode
> state->cft = cft;
> state->cgroup = __d_cgrp(file->f_dentry->d_parent);
> file->f_op = &cgroup_seqfile_operations;
> - err = single_open(file, cgroup_seqfile_show, state);
> +
> + if (!cft->seq_ops)
> + err = single_open(file, cgroup_seqfile_show, state);
> + else {
> + err = seq_open(file, cft->seq_ops);
> + if (!err) {
> + struct seq_file *sf;
> + sf = ((struct seq_file *)file->private_data);
> + sf->private = state;
> + }
> + }
> if (err < 0)
> kfree(state);
> } else if (cft->open)
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-05-20 18:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-20 9:05 [RFC][PATCH 1/3] memcg: documentation for controll file KAMEZAWA Hiroyuki
2008-05-20 9:04 ` Pavel Emelyanov
2008-05-20 9:23 ` KAMEZAWA Hiroyuki
2008-05-20 9:08 ` [RFC][PATCH 2/3] memcg:: seq_ops support for cgroup KAMEZAWA Hiroyuki
2008-05-20 9:23 ` Pavel Emelyanov
2008-05-20 18:46 ` Paul Menage [this message]
2008-05-21 0:28 ` KAMEZAWA Hiroyuki
2008-05-21 5:06 ` Paul Menage
2008-05-21 6:06 ` KAMEZAWA Hiroyuki
2008-05-21 13:08 ` Hirokazu Takahashi
2008-05-20 9:09 ` [RFC][PATCH 3/3] memcg: per node information KAMEZAWA Hiroyuki
2008-05-20 9:33 ` Li Zefan
2008-05-20 10:56 ` KAMEZAWA Hiroyuki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6599ad830805201146g5a2a8928l6a2f5adc51b15f15@mail.gmail.com \
--to=menage@google.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizf@cn.fujitsu.com \
--cc=xemul@openvz.org \
--cc=yamamoto@valinux.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox