From: Balbir Singh <balbir@in.ibm.com>
To: Kirill Korotaev <dev@sw.ru>
Cc: Andrew Morton <akpm@osdl.org>, Rik van Riel <riel@redhat.com>,
ckrm-tech@lists.sourceforge.net,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andi Kleen <ak@suse.de>, Christoph Hellwig <hch@infradead.org>,
Andrey Savochkin <saw@sw.ru>,
devel@openvz.org, hugh@veritas.com, Ingo Molnar <mingo@elte.hu>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Pavel Emelianov <xemul@openvz.org>
Subject: Re: [ckrm-tech] [RFC][PATCH 2/7] UBC: core (structures, API)
Date: Sun, 20 Aug 2006 10:28:41 +0530 [thread overview]
Message-ID: <44E7EC01.5010803@in.ibm.com> (raw)
In-Reply-To: <44E33BB6.3050504@sw.ru>
Kirill Korotaev wrote:
> +/*
> + * Resource list.
> + */
> +
> +#define UB_RESOURCES 0
> +
> +struct ubparm {
> + /*
> + * A barrier over which resource allocations are failed gracefully.
> + * e.g. if the amount of consumed memory is over the barrier further
> + * sbrk() or mmap() calls fail, the existing processes are not killed.
> + */
> + unsigned long barrier;
> + /* hard resource limit */
> + unsigned long limit;
> + /* consumed resources */
> + unsigned long held;
> + /* maximum amount of consumed resources through the last period */
> + unsigned long maxheld;
> + /* minimum amount of consumed resources through the last period */
> + unsigned long minheld;
> + /* count of failed charges */
> + unsigned long failcnt;
> +};
> +
Comments to the side of the field would make it easier to read and understand
the structure. I think there are already other comments requesting for renaming
of the barrier field to hard_limit.
<snip>
> +static inline void ub_adjust_held_minmax(struct user_beancounter *ub,
> + int resource)
> +{
> + if (ub->ub_parms[resource].maxheld < ub->ub_parms[resource].held)
> + ub->ub_parms[resource].maxheld = ub->ub_parms[resource].held;
> + if (ub->ub_parms[resource].minheld > ub->ub_parms[resource].held)
> + ub->ub_parms[resource].minheld = ub->ub_parms[resource].held;
> +}
A comment here to clarify what the function does would be helpful, specially due
to the comparison above
if (maxheld < held)
maxheld = held
if (minheld > held)
minheld = held
<snip>
> +struct user_beancounter ub0;
How about global_ub or init_ub?
> +
> +#define ub_hash_fun(x) ((((x) >> 8) ^ (x)) & (UB_HASH_SIZE - 1))
> +#define ub_subhash_fun(p, id) ub_hash_fun((p)->ub_uid + (id) * 17)
> +
What hash properties are we looking for in the hash function? Is the hash
function universal?
> +struct hlist_head ub_hash[UB_HASH_SIZE];
> +spinlock_t ub_hash_lock;
> +
> +EXPORT_SYMBOL(ub_hash);
> +EXPORT_SYMBOL(ub_hash_lock);
> +
> +/*
> + * Per user 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 user_beancounter *beancounter_findcreate(uid_t uid,
> + struct user_beancounter *p, int mask)
> +{
> + struct user_beancounter *new_ub, *ub, *tmpl_ub;
> + unsigned long flags;
> + struct hlist_head *slot;
> + struct hlist_node *pos;
> +
> + if (mask & UB_LOOKUP_SUB) {
> + WARN_ON(p == NULL);
> + tmpl_ub = &default_subbeancounter;
> + slot = &ub_hash[ub_subhash_fun(p, uid)];
> + } else {
> + WARN_ON(p != NULL);
> + tmpl_ub = &default_beancounter;
> + slot = &ub_hash[ub_hash_fun(uid)];
> + }
> + new_ub = NULL;
> +
> +retry:
> + spin_lock_irqsave(&ub_hash_lock, flags);
> + hlist_for_each_entry (ub, pos, slot, hash)
> + if (ub->ub_uid == uid && ub->parent == p)
> + break;
> +
> + if (pos != NULL) {
> + get_beancounter(ub);
> + spin_unlock_irqrestore(&ub_hash_lock, flags);
> +
> + if (new_ub != NULL) {
> + put_beancounter(new_ub->parent);
> + kmem_cache_free(ub_cachep, new_ub);
> + }
A comment indicative of this being a part of race handing would be useful.
Could you please consider refactoring this function if possible.
> + return ub;
> + }
> +
> + if (!(mask & UB_ALLOC))
> + goto out_unlock;
> +
> + if (new_ub != NULL)
> + goto out_install;
> +
> + if (mask & UB_ALLOC_ATOMIC) {
> + new_ub = kmem_cache_alloc(ub_cachep, GFP_ATOMIC);
> + if (new_ub == NULL)
> + goto out_unlock;
> +
> + memcpy(new_ub, tmpl_ub, sizeof(*new_ub));
> + init_beancounter_struct(new_ub, uid);
> + if (p)
> + new_ub->parent = get_beancounter(p);
> + goto out_install;
> + }
> +
> + spin_unlock_irqrestore(&ub_hash_lock, flags);
> +
> + new_ub = kmem_cache_alloc(ub_cachep, GFP_KERNEL);
> + if (new_ub == NULL)
> + goto out;
> +
> + memcpy(new_ub, tmpl_ub, sizeof(*new_ub));
> + init_beancounter_struct(new_ub, uid);
> + if (p)
> + new_ub->parent = get_beancounter(p);
> + goto retry;
> +
> +out_install:
> + hlist_add_head(&new_ub->hash, slot);
> +out_unlock:
> + spin_unlock_irqrestore(&ub_hash_lock, flags);
> +out:
> + return new_ub;
> +}
> +
> +EXPORT_SYMBOL(beancounter_findcreate);
> +
<snip>
> +void __put_beancounter(struct user_beancounter *ub)
> +{
> + unsigned long flags;
> + struct user_beancounter *parent;
> +
> +again:
> + parent = ub->parent;
> + /* equevalent to atomic_dec_and_lock_irqsave() */
> + local_irq_save(flags);
> + if (likely(!atomic_dec_and_lock(&ub->ub_refcount, &ub_hash_lock))) {
> + if (unlikely(atomic_read(&ub->ub_refcount) < 0))
> + printk(KERN_ERR "UB: Bad ub refcount: ub=%p, "
> + "luid=%d, ref=%d\n",
> + ub, ub->ub_uid,
> + atomic_read(&ub->ub_refcount));
> + local_irq_restore(flags);
> + return;
> + }
> +
> + if (unlikely(ub == &ub0)) {
> + printk(KERN_ERR "Trying to put ub0\n");
> + spin_unlock_irqrestore(&ub_hash_lock, flags);
> + return;
> + }
> +
> + verify_held(ub);
> + hlist_del(&ub->hash);
> + spin_unlock_irqrestore(&ub_hash_lock, flags);
Is this function called with the ub_hash_lock held()? A comment would be useful
or you could call it __put_beancounter_locked :-)
> +
> + kmem_cache_free(ub_cachep, ub);
> +
> + ub = parent;
> + if (ub != NULL)
> + goto again;
Could you please convert this to a do {} while() loop.
> +}
> +
> +EXPORT_SYMBOL(__put_beancounter);
<snip>
> +int charge_beancounter(struct user_beancounter *ub,
> + int resource, unsigned long val, enum severity strict)
> +{
> + int retval;
> + struct user_beancounter *p, *q;
> + unsigned long flags;
> +
> + retval = -EINVAL;
> + BUG_ON(val > UB_MAXVALUE);
> +
> + local_irq_save(flags);
> + for (p = ub; p != NULL; p = p->parent) {
> + spin_lock(&p->ub_lock);
> + retval = __charge_beancounter_locked(p, resource, val, strict);
Everyone in the hierarchy is charged the same amount - val?
> + spin_unlock(&p->ub_lock);
> + if (retval)
> + goto unroll;
> + }
> +out_restore:
> + local_irq_restore(flags);
> + return retval;
> +
> +unroll:
> + for (q = ub; q != p; q = q->parent) {
> + spin_lock(&q->ub_lock);
> + __uncharge_beancounter_locked(q, resource, val);
> + spin_unlock(&q->ub_lock);
> + }
> + goto out_restore;
Too many goto's in both directions - please consider refactoring
> +void charge_beancounter_notop(struct user_beancounter *ub,
> + int resource, unsigned long val)
Whats the meaning of notop?
> +{
> + struct user_beancounter *p;
> + unsigned long flags;
> +
> + local_irq_save(flags);
> + for (p = ub; p->parent != NULL; p = p->parent) {
> + spin_lock(&p->ub_lock);
> + __charge_beancounter_locked(p, resource, val, UB_FORCE);
> + spin_unlock(&p->ub_lock);
> + }
> + local_irq_restore(flags);
> +}
> +
Could some of this code be shared with charge_beancounter to avoid duplication?
> +EXPORT_SYMBOL(charge_beancounter_notop);
> +
> +void __uncharge_beancounter_locked(struct user_beancounter *ub,
> + int resource, unsigned long val)
> +{
> + if (unlikely(ub->ub_parms[resource].held < val)) {
> + ub_print_resource_warning(ub, resource,
> + "uncharging too much", val, 0);
> + val = ub->ub_parms[resource].held;
> + }
> + ub->ub_parms[resource].held -= val;
> + ub_adjust_held_minmax(ub, resource);
> +}
> +
> +void uncharge_beancounter(struct user_beancounter *ub,
> + int resource, unsigned long val)
> +{
> + unsigned long flags;
> + struct user_beancounter *p;
> +
> + for (p = ub; p != NULL; p = p->parent) {
> + spin_lock_irqsave(&p->ub_lock, flags);
> + __uncharge_beancounter_locked(p, resource, val);
> + spin_unlock_irqrestore(&p->ub_lock, flags);
> + }
> +}
> +
> +EXPORT_SYMBOL(uncharge_beancounter);
> +
> +void uncharge_beancounter_notop(struct user_beancounter *ub,
> + int resource, unsigned long val)
> +{
> + struct user_beancounter *p;
> + unsigned long flags;
> +
> + local_irq_save(flags);
> + for (p = ub; p->parent != NULL; p = p->parent) {
> + spin_lock(&p->ub_lock);
> + __uncharge_beancounter_locked(p, resource, val);
> + spin_unlock(&p->ub_lock);
> + }
> + local_irq_restore(flags);
> +}
> +
The code for both uncharge_beancounter() and uncharge_beancounter_notop() seems
to do the same thing
> +
> +void __init ub_init_late(void)
> +{
> + struct user_beancounter *ub;
> +
> + ub_cachep = kmem_cache_create("user_beancounters",
> + sizeof(struct user_beancounter),
> + 0, SLAB_HWCACHE_ALIGN, NULL, NULL);
> + if (ub_cachep == NULL)
> + panic("Can't create ubc caches\n");
> +
> + ub = &default_beancounter;
Whats the relationship between ub0 and default_beancounter?
> + memset(ub, 0, sizeof(default_beancounter));
> + init_beancounter_syslimits(ub);
> + init_beancounter_struct(ub, 0);
Do we need to memset static global variables to 0?
> +
> + ub = &default_subbeancounter;
> + memset(ub, 0, sizeof(default_subbeancounter));
> + init_beancounter_nolimits(ub);
> + init_beancounter_struct(ub, 0);
Do we need to memset static global variables to 0?
> +}
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> ckrm-tech mailing list
> https://lists.sourceforge.net/lists/listinfo/ckrm-tech
--
Regards,
Balbir Singh,
Linux Technology Center,
IBM Software Labs
next prev parent reply other threads:[~2006-08-20 4:58 UTC|newest]
Thread overview: 209+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-16 15:24 [RFC][PATCH] UBC: user resource beancounters Kirill Korotaev
2006-08-16 15:35 ` [RFC][PATCH 1/7] UBC: kconfig Kirill Korotaev
2006-08-18 19:57 ` [ckrm-tech] " Chandra Seetharaman
2006-08-18 21:14 ` Adrian Bunk
2006-08-25 15:12 ` Pavel Machek
2006-08-16 15:37 ` [RFC][PATCH 2/7] UBC: core (structures, API) Kirill Korotaev
2006-08-16 16:58 ` Alan Cox
2006-08-17 11:42 ` Kirill Korotaev
2006-08-16 17:15 ` Greg KH
2006-08-17 11:45 ` Kirill Korotaev
2006-08-17 12:14 ` Greg KH
2006-08-17 14:32 ` [ckrm-tech] " Dave Hansen
2006-08-18 12:36 ` Kirill Korotaev
2006-08-16 18:11 ` Rohit Seth
2006-08-16 18:18 ` Andrew Morton
2006-08-17 11:54 ` Kirill Korotaev
2006-08-17 11:53 ` Kirill Korotaev
2006-08-17 16:55 ` Rohit Seth
2006-08-18 11:14 ` Kirill Korotaev
2006-08-18 17:51 ` Rohit Seth
2006-08-18 5:31 ` Andrew Morton
2006-08-18 7:35 ` [PATCH " Andrey Savochkin
2006-08-18 8:26 ` [ckrm-tech] " Matt Helsley
2006-08-18 11:52 ` Kirill Korotaev
2006-08-18 15:59 ` [RFC][PATCH " Alan Cox
2006-08-17 11:09 ` [ckrm-tech] " Srivatsa Vaddagiri
2006-08-17 14:02 ` Kirill Korotaev
2006-08-17 18:59 ` Chandra Seetharaman
2006-08-18 1:58 ` Matt Helsley
2006-08-18 11:36 ` Kirill Korotaev
2006-08-19 2:38 ` Matt Helsley
2006-08-21 11:02 ` Kirill Korotaev
2006-08-22 12:23 ` Srivatsa Vaddagiri
2006-08-22 12:46 ` Kirill Korotaev
2006-08-22 14:38 ` Srivatsa Vaddagiri
2006-08-21 17:35 ` Chandra Seetharaman
2006-08-20 4:58 ` Balbir Singh [this message]
2006-08-20 5:01 ` Balbir Singh
2006-08-16 15:38 ` [RFC][PATCH 3/7] UBC: ub context and inheritance Kirill Korotaev
2006-08-16 16:51 ` Alan Cox
2006-08-17 11:09 ` [ckrm-tech] " Srivatsa Vaddagiri
2006-08-17 13:21 ` [Devel] " Pavel V. Emelianov
2006-08-18 2:42 ` Matt Helsley
2006-08-18 9:23 ` Kirill Korotaev
2006-08-19 2:19 ` Matt Helsley
2006-08-18 20:03 ` Chandra Seetharaman
2006-08-21 10:32 ` Kirill Korotaev
2006-08-21 20:48 ` Chandra Seetharaman
2006-08-16 15:39 ` [RFC][PATCH 4/7] UBC: syscalls (user interface) Kirill Korotaev
2006-08-16 16:52 ` Alan Cox
2006-08-16 17:17 ` Greg KH
2006-08-17 12:02 ` Kirill Korotaev
2006-08-16 18:17 ` Rohit Seth
2006-08-16 19:04 ` Alan Cox
2006-08-16 19:22 ` Rohit Seth
2006-08-17 12:13 ` Kirill Korotaev
2006-08-17 15:40 ` Andrew Morton
2006-08-18 8:08 ` [PATCH " Andrey Savochkin
2006-08-18 14:45 ` [ckrm-tech] " Dave Hansen
2006-08-18 16:42 ` Andrew Morton
2006-08-18 17:29 ` Dave Hansen
2006-08-18 17:38 ` Andrew Morton
2006-08-18 17:59 ` Rohit Seth
2006-08-18 18:18 ` Andrew Morton
2006-08-21 2:42 ` Magnus Damm
2006-08-18 18:09 ` Paul Jackson
2006-08-18 18:17 ` Chandra Seetharaman
2006-08-18 18:27 ` Chandra Seetharaman
2006-08-18 18:56 ` Paul Jackson
2006-08-18 19:16 ` Chris Friesen
2006-08-18 21:19 ` Paul Jackson
2006-08-18 19:48 ` Chandra Seetharaman
2006-08-18 21:16 ` Paul Jackson
2006-08-21 2:38 ` Magnus Damm
2006-08-21 7:48 ` Andi Kleen
2006-08-21 8:42 ` Magnus Damm
2006-08-21 9:03 ` Andi Kleen
2006-08-21 9:18 ` Magnus Damm
2006-08-21 13:35 ` Kirill Korotaev
2006-08-21 17:51 ` Paul Jackson
2006-08-22 8:52 ` Kirill Korotaev
2006-08-21 2:47 ` Magnus Damm
2006-08-22 1:16 ` Rohit Seth
2006-08-22 3:58 ` Magnus Damm
2006-08-22 18:34 ` Chandra Seetharaman
2006-08-24 1:20 ` Rohit Seth
2006-08-18 11:05 ` [RFC][PATCH " Kirill Korotaev
2006-08-17 17:08 ` Rohit Seth
2006-08-17 12:04 ` Kirill Korotaev
2006-08-17 17:05 ` Rohit Seth
2006-08-17 11:09 ` [ckrm-tech] " Srivatsa Vaddagiri
2006-08-17 14:04 ` Kirill Korotaev
2006-08-17 16:19 ` Srivatsa Vaddagiri
2006-08-18 2:31 ` Matt Helsley
2006-08-18 11:45 ` Kirill Korotaev
2006-08-19 2:43 ` Matt Helsley
2006-08-18 11:40 ` Arnd Bergmann
2006-08-18 20:13 ` [ckrm-tech] " Chandra Seetharaman
2006-08-16 15:40 ` [RFC][PATCH 5/7] UBC: kernel memory accounting (core) Kirill Korotaev
2006-08-16 16:56 ` Alan Cox
2006-08-17 13:47 ` Kirill Korotaev
2006-08-16 18:24 ` Rohit Seth
2006-08-17 13:27 ` Kirill Korotaev
2006-08-17 14:38 ` [ckrm-tech] " Dave Hansen
2006-08-18 9:31 ` Kirill Korotaev
2006-08-18 14:58 ` Dave Hansen
2006-08-21 10:40 ` Kirill Korotaev
2006-08-21 15:10 ` Dave Hansen
2006-08-18 15:06 ` Dave Hansen
2006-08-21 12:38 ` Kirill Korotaev
2006-08-17 17:02 ` Rohit Seth
2006-08-18 9:38 ` Kirill Korotaev
2006-08-18 16:55 ` Rohit Seth
2006-08-21 10:43 ` Kirill Korotaev
2006-08-22 1:23 ` Rohit Seth
2006-08-16 18:47 ` Dave Hansen
2006-08-16 19:15 ` Rohit Seth
2006-08-16 19:59 ` [ckrm-tech] " Dave Hansen
2006-08-17 0:24 ` Alan Cox
2006-08-17 14:26 ` Dave Hansen
2006-08-17 15:01 ` Alan Cox
2006-08-17 16:04 ` Andi Kleen
2006-08-18 10:54 ` Kirill Korotaev
2006-08-17 16:37 ` Dave Hansen
2006-08-17 15:19 ` Rik van Riel
2006-08-17 17:28 ` Rohit Seth
2006-08-17 18:43 ` Andi Kleen
2006-08-17 17:49 ` Dave Hansen
2006-08-18 8:29 ` Kirill Korotaev
2006-08-18 17:06 ` Rohit Seth
2006-08-17 17:16 ` Rohit Seth
2006-08-17 17:23 ` Dave Hansen
2006-08-17 17:36 ` Rohit Seth
2006-08-17 17:53 ` Dave Hansen
2006-08-18 8:54 ` Kirill Korotaev
2006-08-18 14:52 ` Dave Hansen
2006-08-18 17:38 ` Rohit Seth
2006-08-21 11:29 ` Kirill Korotaev
2006-08-22 1:48 ` Rohit Seth
2006-08-22 7:43 ` Pavel V. Emelianov
2006-08-18 8:51 ` Kirill Korotaev
2006-08-18 8:52 ` Kirill Korotaev
2006-08-18 14:59 ` Alan Cox
2006-08-18 19:32 ` Dave Hansen
2006-08-18 20:52 ` Alan Cox
2006-08-21 9:44 ` Kirill Korotaev
2006-08-17 16:42 ` Rohit Seth
2006-08-17 16:31 ` Rohit Seth
2006-08-17 0:22 ` Alan Cox
2006-08-17 16:36 ` Rohit Seth
2006-08-18 8:44 ` [ckrm-tech] " Kirill Korotaev
2006-08-17 13:35 ` Kirill Korotaev
2006-08-17 17:13 ` Rohit Seth
2006-08-18 8:49 ` [ckrm-tech] " Kirill Korotaev
2006-08-17 13:31 ` Kirill Korotaev
2006-08-17 14:36 ` Dave Hansen
2006-08-18 8:12 ` [ckrm-tech] " Kirill Korotaev
2006-08-18 14:43 ` Dave Hansen
2006-08-21 8:57 ` Kirill Korotaev
2006-08-18 20:26 ` Chandra Seetharaman
2006-08-21 10:51 ` Kirill Korotaev
2006-08-21 20:55 ` Chandra Seetharaman
2006-08-16 15:42 ` [RFC][PATCH 6/7] UBC: kernel memory acconting (mark objects) Kirill Korotaev
2006-08-16 16:57 ` Alan Cox
2006-08-16 15:44 ` [RFC][PATCH 7/7] UBC: proc interface Kirill Korotaev
2006-08-16 17:13 ` Greg KH
2006-08-17 13:43 ` Kirill Korotaev
2006-08-17 15:40 ` Greg KH
2006-08-17 16:12 ` [Devel] " Kir Kolyshkin
2006-08-16 18:53 ` [RFC][PATCH] UBC: user resource beancounters Rohit Seth
2006-08-16 19:26 ` Alan Cox
2006-08-17 0:15 ` [ckrm-tech] " Chandra Seetharaman
2006-08-17 11:02 ` Srivatsa Vaddagiri
2006-08-17 13:55 ` Kirill Korotaev
2006-08-17 19:55 ` Chandra Seetharaman
2006-08-18 10:36 ` Kirill Korotaev
2006-08-18 18:53 ` Chandra Seetharaman
2006-08-18 22:55 ` Matt Helsley
2006-08-21 10:55 ` Kirill Korotaev
2006-08-21 21:04 ` Chandra Seetharaman
2006-08-18 19:39 ` Chandra Seetharaman
2006-08-21 13:24 ` Kirill Korotaev
2006-08-21 21:45 ` Chandra Seetharaman
2006-08-21 22:20 ` Alan Cox
2006-08-21 22:44 ` Chandra Seetharaman
2006-08-22 1:45 ` Rohit Seth
2006-08-22 10:02 ` Alan Cox
2006-08-22 9:57 ` Arjan van de Ven
2006-08-22 11:15 ` Alan Cox
2006-08-24 1:31 ` Rohit Seth
2006-08-22 18:55 ` Chandra Seetharaman
2006-08-24 1:44 ` Rohit Seth
2006-08-24 2:04 ` Chandra Seetharaman
2006-08-24 11:10 ` Alan Cox
2006-08-24 23:48 ` Chandra Seetharaman
2006-08-24 23:55 ` Kyle Moffett
2006-08-25 18:21 ` Chandra Seetharaman
2006-08-25 20:46 ` Alan Cox
2006-08-25 21:37 ` Chandra Seetharaman
2006-08-25 22:51 ` Alan Cox
2006-08-25 22:59 ` Chandra Seetharaman
2006-08-24 17:27 ` Rohit Seth
2006-08-24 23:52 ` Chandra Seetharaman
2006-08-25 11:12 ` Kirill Korotaev
2006-08-25 18:47 ` Chandra Seetharaman
2006-08-25 20:52 ` Alan Cox
2006-08-25 22:23 ` Chandra Seetharaman
2006-08-25 23:12 ` Alan Cox
2006-08-25 23:00 ` Chandra Seetharaman
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=44E7EC01.5010803@in.ibm.com \
--to=balbir@in.ibm.com \
--cc=ak@suse.de \
--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=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=riel@redhat.com \
--cc=saw@sw.ru \
--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 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.