From: Andi Kleen <ak@suse.de>
To: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
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: [Lse-tech] Re: [RFC] [PATCH] Scalable Statistics Counters
Date: Fri, 7 Dec 2001 14:23:21 +0100 [thread overview]
Message-ID: <20011207142321.A7652@wotan.suse.de> (raw)
In-Reply-To: <20011205163153.E16315@in.ibm.com> <Pine.LNX.4.33L.0112051109340.4079-100000@imladris.surriel.com> <3C0E7ED9.1F0BD44E@zip.com.au> <20011206141826.16833acc.rusty@rustcorp.com.au> <20011207182214.D15810@in.ibm.com>
In-Reply-To: <20011207182214.D15810@in.ibm.com>
On Fri, Dec 07, 2001 at 06:22:14PM +0530, Dipankar Sarma wrote:
> 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.
Using virtual addresses with per cpu mappings would be rather difficult to
implement for i386, because it uses the linux page table directly in
hardware. It would mean that you couldn't simply reuse the same top level
page for all clone()s sharing the same mm_struct, but would need to allocate
one per CPU.
On i386 the old method from the SGI PDA patch looks cheapest: just having
a pointer in task_struct and set it in the scheduler.
-Andi
next prev parent reply other threads:[~2001-12-07 13:23 UTC|newest]
Thread overview: 8+ 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 ` Andi Kleen [this message]
2001-12-08 7:38 ` Rusty Russell
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=20011207142321.A7652@wotan.suse.de \
--to=ak@suse.de \
--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 \
--cc=rusty@rustcorp.com.au \
/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