From: Rusty Russell <rusty@rustcorp.com.au>
To: dipankar@in.ibm.com
Cc: Andrew Morton <akpm@zip.com.au>,
riel@conectiva.com.br, kiran@in.ibm.com,
lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [RFC] [PATCH] Scalable Statistics Counters
Date: Sat, 08 Dec 2001 18:38:09 +1100 [thread overview]
Message-ID: <E16Cc3l-0001eR-00@wagner> (raw)
In-Reply-To: Your message of "Fri, 07 Dec 2001 18:22:14 +0530." <20011207182214.D15810@in.ibm.com>
In message <20011207182214.D15810@in.ibm.com> you write:
> On Thu, Dec 06, 2001 at 02:18:26PM +1100, Rusty Russell wrote:
> > On Wed, 05 Dec 2001 12:08:57 -0800
> > Andrew Morton <akpm@zip.com.au> wrote:
> >
> > > http://www.zipworld.com.au/~akpm/linux/2.4/2.4.7/
> >
> > Oops, guess I should have read this thread first (still catching up on mail
).
> >
> > Please see my per-cpu patch (just posted under [PATCH] 2.5.1-pre5: per-cpu
> > areas), and my previous /proc patch. Combining the two into convenient for
m
> > is left as an exercise for the reader...
>
> Hi Rusty,
>
> Your per-cpu area patch looks like a good solution with a very simple
> implementation. BTW, some OSes map the per-cpu data areas
> to the same virtual address for each CPU avoiding the per-cpu data
> array lookup. I am not sure if this really saves much, we are ourselves
> trying to understand the overhead of such array lookup with
> statctrs.
I'd be interested in the results: it'd certainly be neater. Another
option would be to use the per-cpu region pointer where architectures
currently hold smp_processor_id(), and derive the current CPU from the
per-CPU area instead of vice versa.
> IIUC, we can declare statically allocated per-cpu data using
> this allocator (kstat, apic_timer_irqs etc.). For things that
> are a part of dynamically allocated structure, we would still
> need to use a dynamic per-cpu allocator, right ?
Yep... Someone Else's Problem 8)
> Another interesting question is how we can load different
> per-cpu sections to different areas in memory. I would suspect
> that for NUMA, we would want to locate the per-cpu sections closest
> to the corresponding CPUs.
It could possibly be done with linker tricks in vmlinux.lds, and yes,
definitely worth doing.
> I couldn't find the /proc patch. Any pointers ?
Hmm... I'm working on a rewrite, but the interface should stay the
same:
http://lists.insecure.org/linux-kernel/2001/Nov/0087.html
Cheers!
Rusty.
--
Anyone who quotes me is an idiot. -- Rusty Russell.
next prev parent reply other threads:[~2001-12-08 7:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-05 11:01 [RFC] [PATCH] Scalable Statistics Counters Ravikiran G Thirumalai
2001-12-05 13:13 ` Rik van Riel
2001-12-05 15:39 ` Dipankar Sarma
2001-12-05 20:08 ` Andrew Morton
2001-12-06 3:18 ` Rusty Russell
2001-12-07 12:52 ` Dipankar Sarma
2001-12-07 13:23 ` [Lse-tech] " Andi Kleen
2001-12-08 7:38 ` Rusty Russell [this message]
[not found] <20011205163153.E16315@in.ibm.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.33L.0112051109340.4079-100000@imladris.surriel.com.suse.lists.linux.kernel>
2001-12-05 14:03 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2001-12-06 12:33 [Lse-tech] " Ravikiran G Thirumalai
2001-12-06 12:59 ` Keith Owens
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=E16Cc3l-0001eR-00@wagner \
--to=rusty@rustcorp.com.au \
--cc=akpm@zip.com.au \
--cc=dipankar@in.ibm.com \
--cc=kiran@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=riel@conectiva.com.br \
/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.