From: Mike Fedyk <mfedyk@matchmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Davide Libenzi <davidel@xmailserver.org>,
Linus Torvalds <torvalds@transmeta.com>,
lkml <linux-kernel@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [patch] scheduler cache affinity improvement for 2.4 kernels
Date: Fri, 9 Nov 2001 00:05:54 -0800 [thread overview]
Message-ID: <20011109000554.A495@mikef-linux.matchmail.com> (raw)
In-Reply-To: <20011108153749.A14468@mikef-linux.matchmail.com> <Pine.LNX.4.33.0111090924400.2240-100000@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.33.0111090924400.2240-100000@localhost.localdomain>
On Fri, Nov 09, 2001 at 09:28:09AM +0100, Ingo Molnar wrote:
>
> On Thu, 8 Nov 2001, Mike Fedyk wrote:
>
> > It remains to be proven whether the coarser scheduling approach
> > (Ingo's) will actually help when looking at cache properties.... [...]
>
> have you seen the numbers/measurements i posted in my original email? 3%
> kernel compile speedup on an 'idle' 8-way system, 7% compilation speedup
> with HZ=1024 and background networking load on a 1-way system.
>
Yep, but it probably won't do as well on my 2x366 celeron system that I use
every day...
Haven't tested, but it looks like there wouldn't be much chance of the third
CPU hog to stay in the caches. That's pretty much flushing the entire cache
of the previous task with the longer periods of execution.
Now, if the number of sequential jiffies were modified based on the L1/L2
cache sizes that would be interesting...
Also Ingo, if you're worried about your processes staying in the cache, I'd
work on the processor affinity before working on this... But, then again,
I'm not you, and I don't know how myself... :(
Mike
next prev parent reply other threads:[~2001-11-09 8:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-08 14:30 [patch] scheduler cache affinity improvement for 2.4 kernels Ingo Molnar
2001-11-08 15:22 ` M. Edward Borasky
2001-11-08 16:33 ` Ingo Molnar
2001-11-08 17:15 ` Davide Libenzi
2001-11-08 18:27 ` Ingo Molnar
2001-11-08 18:03 ` Davide Libenzi
2001-11-08 19:40 ` Ingo Molnar
2001-11-08 19:13 ` Davide Libenzi
2001-11-08 23:37 ` Mike Fedyk
2001-11-09 0:37 ` Davide Libenzi
2001-11-09 1:07 ` Mike Fedyk
2001-11-09 1:29 ` Davide Libenzi
2001-11-09 1:34 ` Mike Fedyk
2001-11-09 2:09 ` Davide Libenzi
2001-11-09 2:08 ` Mike Fedyk
2001-11-19 18:34 ` bill davidsen
2001-11-09 8:28 ` Ingo Molnar
2001-11-09 8:05 ` Mike Fedyk [this message]
2001-11-11 21:18 ` Davide Libenzi
2001-11-11 22:31 ` Davide Libenzi
2001-11-08 23:46 ` Andrea Arcangeli
2001-11-09 0:31 ` Davide Libenzi
2001-11-14 4:56 ` Mike Kravetz
2001-11-14 18:08 ` Davide Libenzi
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=20011109000554.A495@mikef-linux.matchmail.com \
--to=mfedyk@matchmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@transmeta.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