From: Andrew Morton <akpm@linux-foundation.org>
To: Shaohua Li <shaohua.li@intel.com>
Cc: Andi Kleen <andi@firstfloor.org>, linux-mm <linux-mm@kvack.org>,
lkml <linux-kernel@vger.kernel.org>,
Rik van Riel <riel@redhat.com>, Hugh Dickins <hughd@google.com>
Subject: Re: [PATCH]mmap: add alignment for some variables
Date: Tue, 29 Mar 2011 18:25:44 -0700 [thread overview]
Message-ID: <20110329182544.6ad4eccb.akpm@linux-foundation.org> (raw)
In-Reply-To: <1301447843.3981.48.camel@sli10-conroe>
On Wed, 30 Mar 2011 09:17:23 +0800 Shaohua Li <shaohua.li@intel.com> wrote:
> On Wed, 2011-03-30 at 09:06 +0800, Andrew Morton wrote:
> > On Wed, 30 Mar 2011 09:01:22 +0800 Shaohua Li <shaohua.li@intel.com> wrote:
> >
> > > +/*
> > > + * Make sure vm_committed_as in one cacheline and not cacheline shared with
> > > + * other variables. It can be updated by several CPUs frequently.
> > > + */
> > > +struct percpu_counter vm_committed_as ____cacheline_internodealigned_in_smp;
> >
> > The mystery deepens. The only cross-cpu writeable fields in there are
> > percpu_counter.lock and its companion percpu_counter.count. If CPUs
> > are contending for the lock then that itself is a problem - how does
> > adding some padding to the struct help anything?
> I had another patch trying to address the lock contention (for case
> OVERCOMMIT_GUESS), will send out soon. But thought better to have the
> correct alignment for OVERCOMMIT_NEVER case.
I still don't understand why adding
____cacheline_internodealigned_in_smp to vm_committed_as improves
anything.
Here it is:
struct percpu_counter {
spinlock_t lock;
s64 count;
#ifdef CONFIG_HOTPLUG_CPU
struct list_head list; /* All percpu_counters are on a list */
#endif
s32 __percpu *counters;
};
and your patch effectively converts this to
struct percpu_counter {
spinlock_t lock;
s64 count;
#ifdef CONFIG_HOTPLUG_CPU
struct list_head list; /* All percpu_counters are on a list */
#endif
s32 __percpu *counters;
+ char large_waste_of_space[lots];
};
how is it that this improves things?
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Shaohua Li <shaohua.li@intel.com>
Cc: Andi Kleen <andi@firstfloor.org>, linux-mm <linux-mm@kvack.org>,
lkml <linux-kernel@vger.kernel.org>,
Rik van Riel <riel@redhat.com>, Hugh Dickins <hughd@google.com>
Subject: Re: [PATCH]mmap: add alignment for some variables
Date: Tue, 29 Mar 2011 18:25:44 -0700 [thread overview]
Message-ID: <20110329182544.6ad4eccb.akpm@linux-foundation.org> (raw)
In-Reply-To: <1301447843.3981.48.camel@sli10-conroe>
On Wed, 30 Mar 2011 09:17:23 +0800 Shaohua Li <shaohua.li@intel.com> wrote:
> On Wed, 2011-03-30 at 09:06 +0800, Andrew Morton wrote:
> > On Wed, 30 Mar 2011 09:01:22 +0800 Shaohua Li <shaohua.li@intel.com> wrote:
> >
> > > +/*
> > > + * Make sure vm_committed_as in one cacheline and not cacheline shared with
> > > + * other variables. It can be updated by several CPUs frequently.
> > > + */
> > > +struct percpu_counter vm_committed_as ____cacheline_internodealigned_in_smp;
> >
> > The mystery deepens. The only cross-cpu writeable fields in there are
> > percpu_counter.lock and its companion percpu_counter.count. If CPUs
> > are contending for the lock then that itself is a problem - how does
> > adding some padding to the struct help anything?
> I had another patch trying to address the lock contention (for case
> OVERCOMMIT_GUESS), will send out soon. But thought better to have the
> correct alignment for OVERCOMMIT_NEVER case.
I still don't understand why adding
____cacheline_internodealigned_in_smp to vm_committed_as improves
anything.
Here it is:
struct percpu_counter {
spinlock_t lock;
s64 count;
#ifdef CONFIG_HOTPLUG_CPU
struct list_head list; /* All percpu_counters are on a list */
#endif
s32 __percpu *counters;
};
and your patch effectively converts this to
struct percpu_counter {
spinlock_t lock;
s64 count;
#ifdef CONFIG_HOTPLUG_CPU
struct list_head list; /* All percpu_counters are on a list */
#endif
s32 __percpu *counters;
+ char large_waste_of_space[lots];
};
how is it that this improves things?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-03-30 1:25 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-28 1:58 [PATCH]mmap: add alignment for some variables Shaohua Li
2011-03-28 1:58 ` Shaohua Li
2011-03-28 16:55 ` Andi Kleen
2011-03-28 16:55 ` Andi Kleen
2011-03-29 0:54 ` Shaohua Li
2011-03-29 0:54 ` Shaohua Li
2011-03-29 22:24 ` Andrew Morton
2011-03-29 22:24 ` Andrew Morton
2011-03-29 22:38 ` Christoph Lameter
2011-03-29 22:38 ` Christoph Lameter
2011-03-30 1:01 ` Shaohua Li
2011-03-30 1:01 ` Shaohua Li
2011-03-30 1:06 ` Andrew Morton
2011-03-30 1:06 ` Andrew Morton
2011-03-30 1:17 ` Shaohua Li
2011-03-30 1:17 ` Shaohua Li
2011-03-30 1:25 ` Andrew Morton [this message]
2011-03-30 1:25 ` Andrew Morton
2011-03-30 1:36 ` Shaohua Li
2011-03-30 1:36 ` Shaohua Li
2011-03-30 1:41 ` Andrew Morton
2011-03-30 1:41 ` Andrew Morton
2011-03-30 1:54 ` Shaohua Li
2011-03-30 1:54 ` Shaohua Li
2011-03-30 2:10 ` Andrew Morton
2011-03-30 2:10 ` Andrew Morton
2011-03-30 2:35 ` Shaohua Li
2011-03-30 2:35 ` Shaohua Li
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=20110329182544.6ad4eccb.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
--cc=shaohua.li@intel.com \
/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.