From: Andrew Morton <akpm@osdl.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: steiner@sgi.com, mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] - Reduce overhead of calc_load
Date: Fri, 17 Mar 2006 21:13:15 -0800 [thread overview]
Message-ID: <20060317211315.55457f22.akpm@osdl.org> (raw)
In-Reply-To: <441B7489.1090403@yahoo.com.au>
Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
> Andrew Morton wrote:
> > Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
> >>Is there a need? Do they (except calc_load) use multiple values at
> >>the same time?
> >
> >
> > Don't know. It might happen in the future. And the additional cost is
> > practically zero.
> >
>
> Unless it happens to hit another cacheline (cachelines for all other
> CPUs but our own will most likely be invalid on this cpu). In which
> case the cost could double quite easily.
>
That would be an inefficient implementation. Let's not implement it
inefficiently.
> I think it might be better to leave it for the moment. If something comes
> up we can always take a look at it then (it isn't particularly tricky code).
What we're seeing here is a proliferation of little functions, all of which
do the same thing, some of them in different ways.
Take a look at (for example) nr_iowait. We forget to spill the count out
of the departing CPU's runqueue and hence we have to sum it across all
possible CPUs and we don't bother accounting for the possibility of the sum
going negative because we happen to dink with the runqueue of a
now-possibly-downed CPU. It's inefficient and it's inconsistent and some
of it is, or will become incorrect. The other counters there probably have
various combinations of these problems but I can't be bothered checking
them all because they're all implemented differently.
Better to do them all in the one place and do them all the same way. I'd
suggest a cacheline-aligned struct of local_t's which can be queried into a
struct of ulongs.
That query should only look at online CPUs, which becomes rather necessary
if we're to allocate runqueues only for online CPUs (desirable - the thing
is huge).
next prev parent reply other threads:[~2006-03-18 5:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-17 14:57 Jack Steiner
2006-03-17 14:59 ` Ingo Molnar
2006-03-17 15:26 ` Jack Steiner
2006-03-18 1:15 ` Andrew Morton
2006-03-18 2:09 ` Nick Piggin
2006-03-18 2:37 ` Andrew Morton
2006-03-18 2:46 ` Nick Piggin
2006-03-18 5:13 ` Andrew Morton [this message]
2006-03-18 5:38 ` Nick Piggin
2006-03-18 6:10 ` Nick Piggin
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=20060317211315.55457f22.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=steiner@sgi.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
all inboxes | Powered by JetHome®