From: Balbir Singh <balbir@in.ibm.com>
To: Paul Menage <menage@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, vatsa@in.ibm.com,
ckrm-tech@lists.sourceforge.net, xemul@sw.ru, linux-mm@kvack.org,
svaidy@linux.vnet.ibm.com, devel@openvz.org
Subject: Re: [RFC][PATCH][1/4] RSS controller setup
Date: Mon, 19 Feb 2007 16:43:24 +0530 [thread overview]
Message-ID: <45D98654.2020005@in.ibm.com> (raw)
In-Reply-To: <6599ad830702190118r20b477d3q254c167c2fc2732@mail.gmail.com>
Paul Menage wrote:
> On 2/19/07, Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> This output is hard to parse and to extend. I'd suggest either two
>> separate files, or multi-line output:
>>
>> usage: %lu kB
>> limit: %lu kB
>
> Two separate files would be the container usage model that I
> envisaged, inherited from the way cpusets does things.
>
> And in this case, it should definitely be the limit in one file,
> readable and writeable, and the usage in another, probably only
> readable.
>
> Having to read a file called memctlr_usage to find the current limit
> sounds wrong.
>
That sound right, I'll fix this.
> Hmm, I don't appear to have documented this yet, but I think a good
> naming scheme for container files is <subsystem>.<whatever> - i.e.
> these should be memctlr.usage and memctlr.limit. The existing
> grandfathered Cpusets names violate this, but I'm not sure there's a
> lot we can do about that.
>
Why <subsystem>.<whatever>, dots are harder to parse using regular
expressions and sound DOS'ish. I'd prefer "_" to separate the
subsystem and whatever :-)
>> > +static int memctlr_populate(struct container_subsys *ss,
>> > + struct container *cont)
>> > +{
>> > + int rc;
>> > + if ((rc = container_add_file(cont, &memctlr_usage)) < 0)
>> > + return rc;
>> > + if ((rc = container_add_file(cont, &memctlr_limit)) < 0)
>>
>> Clean up the first file here?
>
> Containers don't currently provide an API for a subsystem to clean up
> files from a directory - that's done automatically when the directory
> is deleted.
>
> I think I'll probably change the API for container_add_file to return
> void, but mark an error in the container itself if something goes
> wrong - that way rather than all the subsystems having to check for
> error, container_populate_dir() can do so at the end of calling all
> the subsystems' populate methods.
>
It should be easy to add container_remove_file() instead of marking
an error.
> Paul
--
Warm Regards,
Balbir Singh
WARNING: multiple messages have this Message-ID (diff)
From: Balbir Singh <balbir@in.ibm.com>
To: Paul Menage <menage@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, vatsa@in.ibm.com,
ckrm-tech@lists.sourceforge.net, xemul@sw.ru, linux-mm@kvack.org,
svaidy@linux.vnet.ibm.com, devel@openvz.org
Subject: Re: [RFC][PATCH][1/4] RSS controller setup
Date: Mon, 19 Feb 2007 16:43:24 +0530 [thread overview]
Message-ID: <45D98654.2020005@in.ibm.com> (raw)
In-Reply-To: <6599ad830702190118r20b477d3q254c167c2fc2732@mail.gmail.com>
Paul Menage wrote:
> On 2/19/07, Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> This output is hard to parse and to extend. I'd suggest either two
>> separate files, or multi-line output:
>>
>> usage: %lu kB
>> limit: %lu kB
>
> Two separate files would be the container usage model that I
> envisaged, inherited from the way cpusets does things.
>
> And in this case, it should definitely be the limit in one file,
> readable and writeable, and the usage in another, probably only
> readable.
>
> Having to read a file called memctlr_usage to find the current limit
> sounds wrong.
>
That sound right, I'll fix this.
> Hmm, I don't appear to have documented this yet, but I think a good
> naming scheme for container files is <subsystem>.<whatever> - i.e.
> these should be memctlr.usage and memctlr.limit. The existing
> grandfathered Cpusets names violate this, but I'm not sure there's a
> lot we can do about that.
>
Why <subsystem>.<whatever>, dots are harder to parse using regular
expressions and sound DOS'ish. I'd prefer "_" to separate the
subsystem and whatever :-)
>> > +static int memctlr_populate(struct container_subsys *ss,
>> > + struct container *cont)
>> > +{
>> > + int rc;
>> > + if ((rc = container_add_file(cont, &memctlr_usage)) < 0)
>> > + return rc;
>> > + if ((rc = container_add_file(cont, &memctlr_limit)) < 0)
>>
>> Clean up the first file here?
>
> Containers don't currently provide an API for a subsystem to clean up
> files from a directory - that's done automatically when the directory
> is deleted.
>
> I think I'll probably change the API for container_add_file to return
> void, but mark an error in the container itself if something goes
> wrong - that way rather than all the subsystems having to check for
> error, container_populate_dir() can do so at the end of calling all
> the subsystems' populate methods.
>
It should be easy to add container_remove_file() instead of marking
an error.
> Paul
--
Warm Regards,
Balbir Singh
--
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:[~2007-02-19 11:13 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-19 6:50 [RFC][PATCH][0/4] Memory controller (RSS Control) Balbir Singh
2007-02-19 6:50 ` Balbir Singh
2007-02-19 6:50 ` [RFC][PATCH][1/4] RSS controller setup Balbir Singh
2007-02-19 6:50 ` Balbir Singh
2007-02-19 8:57 ` Andrew Morton
2007-02-19 8:57 ` Andrew Morton
2007-02-19 9:18 ` Paul Menage
2007-02-19 9:18 ` Paul Menage
2007-02-19 11:13 ` Balbir Singh [this message]
2007-02-19 11:13 ` Balbir Singh
2007-02-19 19:43 ` Matthew Helsley
2007-02-19 19:43 ` Matthew Helsley
2007-02-19 10:06 ` Balbir Singh
2007-02-19 10:06 ` Balbir Singh
2007-02-19 6:50 ` [RFC][PATCH][2/4] Add RSS accounting and control Balbir Singh
2007-02-19 6:50 ` Balbir Singh
2007-02-19 8:58 ` Andrew Morton
2007-02-19 8:58 ` Andrew Morton
2007-02-19 10:37 ` [ckrm-tech] " Balbir Singh
2007-02-19 10:37 ` Balbir Singh
2007-02-19 11:01 ` Andrew Morton
2007-02-19 11:01 ` Andrew Morton
2007-02-19 11:09 ` Balbir Singh
2007-02-19 11:09 ` Balbir Singh
2007-02-19 11:23 ` Andrew Morton
2007-02-19 11:23 ` Andrew Morton
2007-02-19 11:56 ` Balbir Singh
2007-02-19 11:56 ` Balbir Singh
2007-02-19 12:09 ` Paul Menage
2007-02-19 12:09 ` Paul Menage
2007-02-19 14:10 ` Balbir Singh
2007-02-19 14:10 ` Balbir Singh
2007-02-19 16:07 ` Vaidyanathan Srinivasan
2007-02-19 16:07 ` Vaidyanathan Srinivasan
2007-02-19 16:17 ` Balbir Singh
2007-02-19 16:17 ` Balbir Singh
2007-02-20 6:40 ` Vaidyanathan Srinivasan
2007-02-20 6:40 ` Vaidyanathan Srinivasan
2007-02-19 6:50 ` [RFC][PATCH][3/4] Add reclaim support Balbir Singh
2007-02-19 6:50 ` Balbir Singh
2007-02-19 8:59 ` Andrew Morton
2007-02-19 8:59 ` Andrew Morton
2007-02-19 10:50 ` Balbir Singh
2007-02-19 10:50 ` Balbir Singh
2007-02-19 11:10 ` Andrew Morton
2007-02-19 11:10 ` Andrew Morton
2007-02-19 11:16 ` Balbir Singh
2007-02-19 11:16 ` Balbir Singh
2007-02-19 9:48 ` KAMEZAWA Hiroyuki
2007-02-19 9:48 ` KAMEZAWA Hiroyuki
2007-02-19 10:52 ` Balbir Singh
2007-02-19 10:52 ` Balbir Singh
2007-02-19 6:50 ` [RFC][PATCH][4/4] RSS controller documentation Balbir Singh
2007-02-19 6:50 ` Balbir Singh
2007-02-19 8:54 ` [RFC][PATCH][0/4] Memory controller (RSS Control) Andrew Morton
2007-02-19 8:54 ` Andrew Morton
2007-02-19 9:06 ` Paul Menage
2007-02-19 9:06 ` Paul Menage
2007-02-19 9:50 ` [ckrm-tech] " Kirill Korotaev
2007-02-19 9:50 ` Kirill Korotaev
2007-02-19 9:50 ` Paul Menage
2007-02-19 9:50 ` Paul Menage
2007-02-19 10:24 ` Balbir Singh
2007-02-19 10:24 ` Balbir Singh
2007-02-19 10:39 ` Balbir Singh
2007-02-19 10:39 ` Balbir Singh
2007-02-19 9:16 ` Magnus Damm
2007-02-19 9:16 ` Magnus Damm
2007-02-19 10:45 ` Balbir Singh
2007-02-19 10:45 ` Balbir Singh
2007-02-19 11:56 ` Magnus Damm
2007-02-19 11:56 ` Magnus Damm
2007-02-19 14:07 ` Balbir Singh
2007-02-19 14:07 ` Balbir Singh
2007-02-19 10:00 ` Balbir Singh
2007-02-19 10:00 ` Balbir Singh
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=45D98654.2020005@in.ibm.com \
--to=balbir@in.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=devel@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=menage@google.com \
--cc=svaidy@linux.vnet.ibm.com \
--cc=vatsa@in.ibm.com \
--cc=xemul@sw.ru \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.