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 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.