From: ebiederm@xmission.com (Eric W. Biederman)
To: Larry McVoy <lm@bitmover.com>
Cc: Jason Papadopoulos <jasonp@boo.net>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: your mail
Date: 25 Jan 2003 10:47:19 -0700 [thread overview]
Message-ID: <m17kctceag.fsf@frodo.biederman.org> (raw)
In-Reply-To: <20030125022648.GA13989@work.bitmover.com>
Larry McVoy <lm@bitmover.com> writes:
> > For the record, I finally got to try my own page coloring patch on a 1GHz
> > Athlon Thunderbird system with 256kB L2 cache. With the present patch, my
> > own number crunching benchmarks and a kernel compile don't show any benefit
> > at all, and lmbench is completely unchanged except for the mmap latency,
> > which is slightly worse. Hardly a compelling case for PCs!
>
> If it works correctly then the variability in lat_ctx should go away.
> Try this
>
> for p in 2 4 8 12 16 24 32 64
> do for size in 0 2 4 8 16
> do for i in 1 2 3 4 5 6 7 8 9 0
> do lat_ctx -s$size $p
> done
> done
> done
>
> on both the with and without kernel. The page coloring should make the
> numbers rock steady, without it, they will bounce a lot.
On the same kind of vein I have seen some tremendous variability in the
stream benchmark. Under linux I have gotten it to very as much
as a 100MB/sec by running updatedb, between runs. In one case
it ran faster with updatedb running in the background.
But at the same time streams tends to be very steady if you have a quiet
machine and run it several times in a row repeatedly because it gets
allocated essentially the same memory every run.
So I do no the variables of cache contention do have effect on some
real programs. I have not yet tracked it down to see if cache coloring
could be a benefit. I suspect the buddy allocator actually comes
quite close most of the time, and tricks like allocating multiple pages
at once could improve that even more with very little effort, while reducing
page fault miss times.
I am wondering if there is any point in biasing page addresses in between
processes so that processes are less likely to have a cache conflict.
i.e. process 1 address 0 %16K == 0, process 2 address 0 %16K == 4K
Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next prev parent reply other threads:[~2003-01-25 17:47 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-24 5:08 (unknown), Anoop J.
2003-01-24 5:11 ` your mail David Lang
2003-01-24 6:06 ` John Alvord
2003-01-25 2:29 ` Jason Papadopoulos
2003-01-25 2:26 ` Larry McVoy
2003-01-25 17:47 ` Eric W. Biederman [this message]
2003-01-25 23:10 ` Larry McVoy
2003-01-26 8:12 ` David S. Miller
-- strict thread matches above, loose matches on Subject: below --
2025-02-24 22:52 [PATCH v7 0/7] mseal system mappings jeffxu
2025-02-25 15:18 ` Lorenzo Stoakes
2025-02-26 0:12 ` Jeff Xu
2025-02-26 5:42 ` your mail Lorenzo Stoakes
2025-02-28 0:55 ` Jeff Xu
2025-02-28 9:35 ` Lorenzo Stoakes
2025-02-28 17:24 ` Jeff Xu
2025-02-28 17:30 ` Lorenzo Stoakes
2023-05-10 19:01 [PATCH] maple_tree: Fix a few documentation issues, Thomas Gleixner
2023-05-15 19:27 ` your mail Liam R. Howlett
2023-05-15 21:16 ` Thomas Gleixner
2023-05-16 22:47 ` Thomas Gleixner
2023-05-23 13:46 ` Liam R. Howlett
[not found] <20190225201635.4648-1-hannes@cmpxchg.org>
2019-02-26 23:49 ` Roman Gushchin
2017-04-10 11:03 [PATCH -v2 0/9] mm: make movable onlining suck less Michal Hocko
2017-04-15 12:17 ` Michal Hocko
2017-04-17 5:47 ` your mail Joonsoo Kim
2017-04-17 8:15 ` Michal Hocko
2017-04-20 1:27 ` Joonsoo Kim
2017-04-20 7:28 ` Michal Hocko
2017-04-20 8:49 ` Michal Hocko
2017-04-20 11:56 ` Vlastimil Babka
2017-04-20 12:13 ` Michal Hocko
2017-04-21 4:38 ` Joonsoo Kim
2017-04-21 7:16 ` Michal Hocko
2017-04-24 1:44 ` Joonsoo Kim
2017-04-24 7:53 ` Michal Hocko
2017-04-25 2:50 ` Joonsoo Kim
2017-04-26 9:19 ` Michal Hocko
2017-04-27 2:08 ` Joonsoo Kim
2017-04-27 15:10 ` Michal Hocko
2012-10-04 16:50 Andrea Arcangeli
2012-10-04 18:17 ` your mail Christoph Lameter
2010-06-16 16:33 Jan Kara
2010-06-16 22:15 ` your mail Dave Chinner
2010-06-22 2:59 ` Wu Fengguang
2010-06-22 13:54 ` Jan Kara
2010-06-22 14:12 ` Wu Fengguang
[not found] <1131.86.55.168.2.1170690089.squirrel@mail.thinknet.ro>
2007-02-05 12:36 ` Joerg Roedel
2003-01-24 5:54 Anoop J.
2003-01-24 6:28 ` David Lang
2003-01-24 8:51 ` Anoop J.
2003-01-24 8:48 ` David Lang
2003-01-24 9:49 ` Anoop J.
2003-01-24 19:14 ` David Lang
2003-01-24 19:40 ` Maciej W. Rozycki
2002-04-21 14:54 raciel
2002-04-21 19:12 ` your mail William Lee Irwin III
2002-01-02 14:20 mehul radheshyam choube
2002-01-03 16:40 ` your mail Rik van Riel
2001-08-04 11:10 Mahmoud Taghizadeh
2001-08-04 13:18 ` your mail Francois Romieu
2001-06-08 1:36 jnn
2001-06-08 13:16 ` your mail Ralf Baechle
2000-09-04 12:01 Sahil
2000-09-04 15:35 ` your mail Rik van Riel
2000-03-28 8:19 pnilesh
2000-03-28 13:26 ` Stephen C. Tweedie
1998-02-25 22:15 Rik van Riel
1998-02-25 22:48 ` your mail Linus Torvalds
1998-02-25 23:26 ` Rik van Riel
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=m17kctceag.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=jasonp@boo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lm@bitmover.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