[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6599ad830611241609r24384d97ic6920f94bc735334@mail.gmail.com>
Date: Fri, 24 Nov 2006 16:09:03 -0800
From: "Paul Menage" <menage@...gle.com>
To: "Pavel Emelianov" <xemul@...nvz.org>
Cc: "Kirill Korotaev" <dev@...ru>, "Andrew Morton" <akpm@...l.org>,
ckrm-tech@...ts.sourceforge.net,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
matthltc@...ibm.com, hch@...radead.org,
"Alan Cox" <alan@...rguk.ukuu.org.uk>, oleg@...sign.ru,
devel@...nvz.org
Subject: Re: [ckrm-tech] [PATCH 4/13] BC: context handling
On 11/24/06, Pavel Emelianov <xemul@...nvz.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.
>
> 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'd appreciate any feedback you had on that approach.
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists