From: Andrew Morton <akpm@osdl.org>
To: Kirill Korotaev <dev@sw.ru>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Christoph Hellwig <hch@infradead.org>,
Pavel Emelianov <xemul@openvz.org>, Andrey Savochkin <saw@sw.ru>,
devel@openvz.org, Rik van Riel <riel@redhat.com>,
Andi Kleen <ak@suse.de>, Greg KH <greg@kroah.com>,
Oleg Nesterov <oleg@tv-sign.ru>,
Matt Helsley <matthltc@us.ibm.com>,
Rohit Seth <rohitseth@google.com>,
Chandra Seetharaman <sekharan@us.ibm.com>
Subject: Re: [PATCH 2/6] BC: beancounters core (API)
Date: Wed, 23 Aug 2006 09:42:02 -0700 [thread overview]
Message-ID: <20060823094202.ff3a5573.akpm@osdl.org> (raw)
In-Reply-To: <44EC35EB.1030000@sw.ru>
On Wed, 23 Aug 2006 15:03:07 +0400
Kirill Korotaev <dev@sw.ru> wrote:
> Core functionality and interfaces of BC:
> find/create beancounter, initialization,
> charge/uncharge of resource, core objects' declarations.
>
> Basic structures:
> bc_resource_parm - resource description
> beancounter - set of resources, id, lock
>
>
> ..
>
> +enum severity { BC_BARRIER, BC_LIMIT, BC_FORCE };
That's a bit generic-sounding. Make it bc_severity?
> +static inline void bc_adjust_held_minmax(struct beancounter *bc,
> + int resource)
> +{
> + if (bc->bc_parms[resource].maxheld < bc->bc_parms[resource].held)
> + bc->bc_parms[resource].maxheld = bc->bc_parms[resource].held;
> + if (bc->bc_parms[resource].minheld > bc->bc_parms[resource].held)
> + bc->bc_parms[resource].minheld = bc->bc_parms[resource].held;
> +}
That might be a bit big to inline.
Suggest you check that the compiler successfully CSE's the
`bc->bc_parms[resource]' evaulation. If not, create a temporary.
> +#define beancounter_findcreate(id, f) (NULL)
> +#define get_beancounter(bc) (NULL)
> +#define put_beancounter(bc) do { } while (0)
> +#define bc_charge_locked(bc, r, v, s) (0)
> +#define bc_charge(bc, r, v) (0)
akpm:/home/akpm> cat t.c
void foo(void)
{
(0);
}
akpm:/home/akpm> gcc -c -Wall t.c
t.c: In function 'foo':
t.c:4: warning: statement with no effect
> +#define bc_hash_fun(x) ((((x) >> 8) ^ (x)) & (BC_HASH_SIZE - 1))
Use hash_long()?
> +/*
> + * Per resource beancounting. Resources are tied to their luid.
> + * The resource structure itself is tagged both to the process and
> + * the charging resources (a socket doesn't want to have to search for
> + * things at irq time for example). Reference counters keep things in
> + * hand.
> + *
> + * The case where a user creates resource, kills all his processes and
> + * then starts new ones is correctly handled this way. The refcounters
> + * will mean the old entry is still around with resource tied to it.
> + */
> +
> +struct beancounter *beancounter_findcreate(uid_t uid, int mask)
> +{
> + struct beancounter *new_bc, *bc;
> + unsigned long flags;
> + struct hlist_head *slot;
> + struct hlist_node *pos;
> +
> + slot = &bc_hash[bc_hash_fun(uid)];
> + new_bc = NULL;
> +
> +retry:
> + spin_lock_irqsave(&bc_hash_lock, flags);
> + hlist_for_each_entry (bc, pos, slot, hash)
> + if (bc->bc_id == uid)
> + break;
> +
> + if (pos != NULL) {
> + get_beancounter(bc);
> + spin_unlock_irqrestore(&bc_hash_lock, flags);
> +
> + if (new_bc != NULL)
> + kmem_cache_free(bc_cachep, new_bc);
> + return bc;
> + }
> +
> + if (!(mask & BC_ALLOC))
> + goto out_unlock;
> +
> + if (new_bc != NULL)
> + goto out_install;
> +
> + spin_unlock_irqrestore(&bc_hash_lock, flags);
> +
> + new_bc = kmem_cache_alloc(bc_cachep,
> + mask & BC_ALLOC_ATOMIC ? GFP_ATOMIC : GFP_KERNEL);
> + if (new_bc == NULL)
> + goto out;
> +
> + memcpy(new_bc, &default_beancounter, sizeof(*new_bc));
> + init_beancounter_struct(new_bc, uid);
> + goto retry;
> +
> +out_install:
> + hlist_add_head(&new_bc->hash, slot);
> +out_unlock:
> + spin_unlock_irqrestore(&bc_hash_lock, flags);
> +out:
> + return new_bc;
> +}
Can remove the global bc_hash_lock and make the locking per-hash-bucket.
> +static inline void verify_held(struct beancounter *bc)
> +{
> + int i;
> +
> + for (i = 0; i < BC_RESOURCES; i++)
> + if (bc->bc_parms[i].held != 0)
> + bc_print_resource_warning(bc, i,
> + "resource is held on put", 0, 0);
> +}
> +
> +void __put_beancounter(struct beancounter *bc)
> +{
> + unsigned long flags;
> +
> + /* equivalent to atomic_dec_and_lock_irqsave() */
> + local_irq_save(flags);
> + if (likely(!atomic_dec_and_lock(&bc->bc_refcount, &bc_hash_lock))) {
> + local_irq_restore(flags);
> + if (unlikely(atomic_read(&bc->bc_refcount) < 0))
> + printk(KERN_ERR "BC: Bad refcount: bc=%p, "
> + "luid=%d, ref=%d\n",
> + bc, bc->bc_id,
> + atomic_read(&bc->bc_refcount));
> + return;
> + }
> +
> + BUG_ON(bc == &init_bc);
> + verify_held(bc);
> + hlist_del(&bc->hash);
> + spin_unlock_irqrestore(&bc_hash_lock, flags);
> + kmem_cache_free(bc_cachep, bc);
> +}
I wonder if it's safe and worthwhile to optimise away the local_irq_save():
if (atomic_dec_and_test(&bc->bc_refcount)) {
spin_lock_irqsave(&bc_hash_lock, flags);
if (atomic_read(&bc->bc_refcount) == 0) {
free it
next prev parent reply other threads:[~2006-08-23 16:46 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-23 10:46 [PATCH] BC: resource beancounters (v2) Kirill Korotaev
2006-08-23 11:01 ` [PATCH 1/6] BC: kconfig Kirill Korotaev
2006-08-23 13:04 ` Alexey Dobriyan
2006-08-23 22:04 ` [Devel] " Dave Hansen
2006-08-23 22:13 ` Matt Helsley
2006-08-23 22:32 ` Randy.Dunlap
2006-08-23 22:27 ` Matt Helsley
2006-08-25 11:30 ` Kirill Korotaev
2006-08-25 11:34 ` Kirill Korotaev
2006-08-24 0:23 ` Chandra Seetharaman
2006-08-24 11:47 ` [ckrm-tech] " Kirill Korotaev
2006-08-24 22:23 ` Matt Helsley
2006-08-23 11:03 ` [PATCH 2/6] BC: beancounters core (API) Kirill Korotaev
2006-08-23 11:37 ` Andi Kleen
2006-08-23 13:27 ` Kirill Korotaev
2006-08-23 13:48 ` Andi Kleen
2006-08-23 13:30 ` Alexey Dobriyan
2006-08-23 13:49 ` Kirill Korotaev
2006-08-23 13:53 ` Alexey Dobriyan
2006-08-23 22:05 ` Matt Helsley
2006-08-23 16:42 ` Andrew Morton [this message]
2006-08-24 12:06 ` Kirill Korotaev
2006-08-24 15:00 ` Andrew Morton
2006-08-25 10:53 ` Kirill Korotaev
2006-08-24 14:13 ` Oleg Nesterov
2006-08-24 21:33 ` Oleg Nesterov
2006-08-23 11:05 ` [PATCH 3/6] BC: context inheriting and changing Kirill Korotaev
2006-08-23 11:06 ` [PATCH 4/6] BC: user interface (syscalls) Kirill Korotaev
2006-08-23 13:41 ` Alexey Dobriyan
2006-08-23 13:43 ` Kirill Korotaev
2006-08-23 16:50 ` Andrew Morton
2006-08-23 17:29 ` Alan Cox
2006-08-24 4:35 ` Andrew Morton
2006-08-24 11:04 ` Alan Cox
2006-08-24 13:08 ` Alexey Dobriyan
2006-08-25 10:56 ` Kirill Korotaev
2006-08-24 0:30 ` Chandra Seetharaman
2006-08-23 11:06 ` [PATCH 5/6] BC: kernel memory accounting (core) Kirill Korotaev
2006-08-24 0:36 ` Chandra Seetharaman
2006-08-24 21:23 ` Oleg Nesterov
2006-08-25 10:09 ` Kirill Korotaev
2006-08-23 11:08 ` [PATCH 6/6] BC: kernel memory accounting (marks) Kirill Korotaev
2006-08-23 18:30 ` [Devel] " Dave Hansen
2006-08-29 9:52 ` Kirill Korotaev
2006-08-29 15:48 ` Dave Hansen
2006-08-29 15:56 ` Kirill Korotaev
2006-08-23 23:03 ` Dave Hansen
2006-08-24 9:30 ` Geert Uytterhoeven
2006-08-24 15:52 ` Dave Hansen
2006-08-29 14:37 ` Kirill Korotaev
2006-08-23 17:05 ` [PATCH] BC: resource beancounters (v2) Andrew Morton
2006-08-24 0:17 ` Chandra Seetharaman
2006-08-25 11:49 ` Kirill Korotaev
2006-08-25 14:30 ` Andrew Morton
2006-08-25 14:48 ` Andi Kleen
2006-08-28 8:28 ` Kirill Korotaev
2006-08-25 15:14 ` Nick Piggin
2006-08-25 15:57 ` Alan Cox
2006-08-26 3:55 ` Nick Piggin
2006-08-25 16:30 ` Andrey Savochkin
2006-08-25 17:50 ` Andrew Morton
2006-08-25 19:00 ` Chandra Seetharaman
2006-08-26 2:15 ` Rohit Seth
2006-08-26 16:37 ` Alan Cox
2006-08-28 16:48 ` Rohit Seth
2006-08-28 17:41 ` [Devel] " Kir Kolyshkin
2006-08-28 22:28 ` Rohit Seth
2006-08-29 10:15 ` Alan Cox
2006-08-29 17:30 ` Rohit Seth
2006-08-29 19:06 ` Alan Cox
2006-08-29 19:15 ` Rohit Seth
2006-08-29 15:35 ` [PATCH] " Kirill Korotaev
2006-08-29 17:08 ` Balbir Singh
2006-08-23 21:00 ` Cedric Le Goater
2006-08-24 5:52 ` Jan Engelhardt
2006-08-24 10:59 ` Alan Cox
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=20060823094202.ff3a5573.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=ak@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dev@sw.ru \
--cc=devel@openvz.org \
--cc=greg@kroah.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=oleg@tv-sign.ru \
--cc=riel@redhat.com \
--cc=rohitseth@google.com \
--cc=saw@sw.ru \
--cc=sekharan@us.ibm.com \
--cc=xemul@openvz.org \
/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
Powered by JetHome