From: Pavel Emelianov <xemul@openvz.org>
To: Paul Menage <menage@google.com>
Cc: Kirill Korotaev <dev@sw.ru>, Andrew Morton <akpm@osdl.org>,
ckrm-tech@lists.sourceforge.net,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
matthltc@us.ibm.com, hch@infradead.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
oleg@tv-sign.ru, devel@openvz.org
Subject: Re: [ckrm-tech] [PATCH 4/13] BC: context handling
Date: Mon, 27 Nov 2006 11:27:41 +0300 [thread overview]
Message-ID: <456AA17D.9020205@openvz.org> (raw)
In-Reply-To: <6599ad830611241609r24384d97ic6920f94bc735334@mail.gmail.com>
Paul Menage wrote:
> On 11/24/06, Pavel Emelianov <xemul@openvz.org> wrote:
>> I've got it! That's what will work:
>>
>> struct task_struct {
>> ...
>> struct beancounter *exec_bc;
>> struct beancounter *tmp_exec_bc; /* is set to NULL on
>> * tsk creation
>> */
>> };
>>
>> struct beancounter get_exec_bc(void)
>> {
>> if (current->tmp_exec_bc)
>> return current->tmp_exec_bc;
>> return rcu_dereference(current->exec_bc);
>> }
>
> Don't forget that this means all callers need to be in an
> rcu_read_lock() section.
Sure. This is done for these particular cases.
>>
>> I will implement this in the next beancounter patches.
>
> This is looking remarkably like the mechanism in use for my generic
> containers patches (inherited from Paul Jackson's cpusets code). In
> the last set of patches that I posted on Wednesday night, I included
> the example of the beancounters core and numfiles counter implemented
> on top of the generic containers - basically pulling out the hash
> table, refcounting and most of the configfs code (since that's handled
> by the generic containers), and moving the attribute management
> configfs code to the use the containerfs filesystem interface instead.
> The rest is pretty much unchanged.
>
> I think you could continue to use the tmp_exec_bc idea with this, and
> have get_exec_bc() use the tmp_exec_bc if it existed, or else get the
> bc pointer via the container system.
I'll look through your patches this week and send my opinion.
> I'd appreciate any feedback you had on that approach.
>
> Paul
next prev parent reply other threads:[~2006-11-27 8:32 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-09 16:49 BC: resource beancounters (v6) (with userpages reclamation + configfs) Kirill Korotaev
2006-11-09 16:53 ` [PATCH 1/13] BC: atomic_dec_and_lock_irqsave() helper Kirill Korotaev
2006-11-10 15:19 ` Cedric Le Goater
2006-11-10 16:46 ` Kirill Korotaev
2006-11-09 16:54 ` [PATCH 2/13] BC: Kconfig and Makefile Kirill Korotaev
2006-11-09 16:55 ` [PATCH 3/13] BC: beancounters core and API Kirill Korotaev
2006-11-09 16:57 ` [PATCH 4/13] BC: context handling Kirill Korotaev
2006-11-23 7:48 ` [ckrm-tech] " Paul Menage
2006-11-23 8:35 ` Pavel Emelianov
2006-11-23 8:53 ` Paul Menage
2006-11-23 9:20 ` Pavel Emelianov
2006-11-23 9:31 ` Paul Menage
2006-11-23 9:56 ` Pavel Emelianov
2006-11-23 10:18 ` Paul Menage
2006-11-23 10:45 ` Pavel Emelianov
2006-11-24 10:10 ` Pavel Emelianov
2006-11-25 0:09 ` Paul Menage
2006-11-27 8:27 ` Pavel Emelianov [this message]
2006-11-09 16:59 ` [PATCH 5/13] BC: configfs interface Kirill Korotaev
2006-11-09 17:00 ` [PATCH 6/13] BC: kmemsize accounting (core) Kirill Korotaev
2006-11-09 19:05 ` Paul Jackson
2006-11-10 22:46 ` Pekka Enberg
2006-11-13 12:13 ` Pavel Emelianov
2006-11-10 22:50 ` Pekka Enberg
2006-11-11 5:50 ` Pavel Machek
2006-11-09 17:01 ` [PATCH 7/13] BC: kmemsize accounting (hooks) Kirill Korotaev
2006-11-09 17:02 ` [PATCH 8/13] BC: privvmpages accounting (core) Kirill Korotaev
2006-11-09 17:04 ` [PATCH 9/13] BC: privvmpages accounting (hooks) Kirill Korotaev
2006-11-09 17:06 ` [PATCH 10/13] BC: physpages accounting (core) Kirill Korotaev
2006-11-09 17:08 ` [PATCH 11/13] BC: physpages accounting (hooks) Kirill Korotaev
2006-11-09 17:09 ` [PATCH 12/13] BC: numtasks accounting Kirill Korotaev
2006-11-09 17:09 ` [PATCH 13/13] BC: numfiles accounting Kirill Korotaev
2006-11-19 19:41 ` BC: resource beancounters (v6) (with userpages reclamation + configfs) Herbert Poetzl
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=456AA17D.9020205@openvz.org \
--to=xemul@openvz.org \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=dev@sw.ru \
--cc=devel@openvz.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=menage@google.com \
--cc=oleg@tv-sign.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox