From: Shuji YAMAMURA <yamamura@flab.fujitsu.co.jp>
To: manfred@colorfullife.com
Cc: davidel@xmailserver.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] task_struct + kernel stack colouring ...
Date: Thu, 06 Dec 2001 17:34:35 +0900 [thread overview]
Message-ID: <20011206173435L.yamamura@flab.fujitsu.co.jp> (raw)
In-Reply-To: <3C0E84B4.1070808@colorfullife.com>
In-Reply-To: <Pine.LNX.4.40.0112051103100.1644-100000@blue1.dev.mcafeelabs.com> <3C0E84B4.1070808@colorfullife.com>
From: Manfred Spraul <manfred@colorfullife.com>
Subject: Re: [PATCH] task_struct + kernel stack colouring ...
Date: Wed, 05 Dec 2001 21:33:56 +0100
Message-ID: <3C0E84B4.1070808@colorfullife.com>
> Shuij, I don't understand why you need both a shift and a modulo:
> address % odd_number should generate a random distribution (i.e. all
> bits affect the result), even without the shift.
Yes, you are right. The shift operation is unnecessary.
Sorry for your confusion.
And probably, the modulo method is better than copying bits, because
it does not depend on the cache configuration.
My posted patch did't use modulo in order to avoid the overhead of
get_current(), which is frequently called. But, copy_thread() is
called once to generate a process, so such overhead may not be the
problem.
Additionally, we measured cache line conflict statistics of stack tops
by snapshotting them during running of apache on 1MB L2-cache system.
The modulo colouring certainly reduces the cache line collisions.
# of tasks # of cache line # of collisions
used AVG(MAX)
--------------------------------------------------------------
Davide's Patch 246 32 7.68(14)
(original)
Davide's Patch 244 165 1.48(6)
(copying 16 to 18 bits)
Davide's Patch 244 164 1.49(4)
(modulo 9)
but, we could't see the meaningful performance difference among them
at least in this experimentation.
Thank you,
-----
Computer Systems Laboratories, Fujitsu Labs.
Shuji YAMAMURA (yamamura@flab.fujitsu.co.jp)
prev parent reply other threads:[~2001-12-06 8:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-04 2:13 [PATCH] task_struct + kernel stack colouring Davide Libenzi
2001-12-05 12:22 ` Shuji YAMAMURA
2001-12-05 19:23 ` Davide Libenzi
2001-12-05 20:33 ` Manfred Spraul
2001-12-05 21:00 ` Davide Libenzi
2001-12-06 0:12 ` kumon
2001-12-06 8:34 ` Shuji YAMAMURA [this message]
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=20011206173435L.yamamura@flab.fujitsu.co.jp \
--to=yamamura@flab.fujitsu.co.jp \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.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