From: Dipankar Sarma <dipankar@in.ibm.com>
To: Niels Christiansen <nchr@us.ibm.com>
Cc: kiran@linux.ibm.com, lse-tech@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [Lse-tech] [RFC] [PATCH] Scalable Statistics Counters
Date: Fri, 7 Dec 2001 14:24:48 +0530 [thread overview]
Message-ID: <20011207142448.A15810@in.ibm.com> (raw)
In-Reply-To: <OF5920A1C3.B32C93AF-ON85256B1A.005706AC@raleigh.ibm.com>
In-Reply-To: <OF5920A1C3.B32C93AF-ON85256B1A.005706AC@raleigh.ibm.com>; from nchr@us.ibm.com on Thu, Dec 06, 2001 at 10:10:47AM -0600
Hi Niels,
On Thu, Dec 06, 2001 at 10:10:47AM -0600, Niels Christiansen wrote:
>
> Hi Kiran,
>
> > Are you concerned with increase in memory used per counter Here? I
> suppose
> > that must not be that much of an issue for a 16 processor box....
>
> Nope, I'm concerned that if this mechanism is to be used for all counters,
> the improvement in cache coherence might be less significant to the point
> where the additional overhead isn't worth it.
In a low-cpu-count SMP box, yes, this will be a concern. Kiran and I
do plan to study this and understand the impact.
>
> Arjab van de Ven voiced similar concerns but he also said:
>
> > There's several things where per cpu data is useful; low frequency
> > statistics is not one of them in my opinion.
>
> ...which may be true for 4-ways and even 8-ways but when you get to
> 32-ways and greater, you start seeing cache problems. That was the
> case on AIX and per-cpu counters was one of the changes that helped
> get the spectacular scalability on Regatta.
Yes. It also helped us in DYNIX/ptx on Sequent boxes. What we
need to do is to verify if theory based on prior experience is
also applicable to linux.
>
> Anyway, since we just had a long thread going on NUMA topology, maybe
> it would be proper to investigate if there is a better way, such as
> using the topology to decide where to put counters? I think so, seeing
> as it is that most Intel based 8-ways and above will have at least some
> NUMA in them.
It should be easy to place the counters in appropriately close
memory if linux gets good NUMA APIs built on top of the topology
services. If we extend kmem_cache_alloc() to allocate memory
in a particular NUMA node, we could simply do this for placing the
counters -
static int pcpu_ctr_mem_grow(struct pcpu_ctr_ctl *ctl, int flags)
{
void *addr;
struct pcpu_ctr_blk *blkp;
unsigned int save_flags;
int i;
if (!(blkp = pcpu_ctr_blkctl_alloc(ctl, flags)))
return 0;
/* Get per cpu cache lines for the block */
for_each_cpu(cpu) {
blkp->lineaddr[cpu] = kmem_cache_alloc_node(ctl->cachep,
flags, CPU_TO_NODE(cpu));
if(!(blkp->lineaddr[cpu]))
goto exit1;
memset(blkp->lineaddr[cpu], 0, PCPU_CTR_LINE_SIZE);
}
This would put the block of counters corresponding to a CPU in
memory local to the NUMA node. If there are more sophisticated
APIs available for suitable memory selection, those too can be made
use of here.
Is this the kind of thing you are looking at ?
Thanks
Dipankar
--
Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
next prev parent reply other threads:[~2001-12-07 8:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-06 16:10 [Lse-tech] [RFC] [PATCH] Scalable Statistics Counters Niels Christiansen
2001-12-07 8:54 ` Dipankar Sarma [this message]
2001-12-08 22:24 ` Paul Jackson
2001-12-09 3:46 ` Jack Steiner
2001-12-09 4:44 ` Paul Jackson
2001-12-09 17:34 ` Jack Steiner
2001-12-11 23:27 ` Paul Jackson
2001-12-07 11:39 ` Ravikiran G Thirumalai
2001-12-08 13:46 ` Anton Blanchard
-- strict thread matches above, loose matches on Subject: below --
2001-12-09 10:57 Manfred Spraul
2001-12-10 16:32 ` Jack Steiner
2001-12-10 17:00 ` Manfred Spraul
2001-12-08 17:43 Niels Christiansen
2001-12-09 11:46 ` Anton Blanchard
2001-12-07 9:52 Niels Christiansen
2001-12-07 10:10 ` Dipankar Sarma
2001-12-05 15:02 Niels Christiansen
2001-12-06 12:33 ` Ravikiran G Thirumalai
2001-12-06 13:07 ` Arjan van de Ven
2001-12-06 14:09 ` Ravikiran G Thirumalai
2001-12-06 14:10 ` Arjan van de Ven
2001-12-06 19:35 ` Dipankar Sarma
2001-12-07 21:09 ` Alex Bligh - linux-kernel
2001-12-07 21:16 ` Arjan van de Ven
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=20011207142448.A15810@in.ibm.com \
--to=dipankar@in.ibm.com \
--cc=kiran@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=nchr@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox