From: Cort Dougan <cort@fsmlabs.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Paul Mackerras <paulus@samba.org>, linux-kernel@vger.kernel.org
Subject: Re: 7.52 second kernel compile
Date: Mon, 18 Mar 2002 14:34:31 -0700 [thread overview]
Message-ID: <20020318143431.E4783@host110.fsmlabs.com> (raw)
In-Reply-To: <20020318124215.C4155@host110.fsmlabs.com> <Pine.LNX.4.33.0203181146070.4783-100000@home.transmeta.com>
I agree with you there. On many PowerPC's, we're screwed. The best thing
I can think of is the clever VSID allocation and trying to make a sane data
structure out of the hash table but that would involve a _lot_ of work with
very likely no reward.
} Hashes simply do not do the right thing. You cannot do a speculative load
} from a hash, and the hash overhead gets _bigger_ for TLB loads that miss
} (ie they optimize for the hit case, which is the wrong optimization if the
} on-chip TLB is big enough - and since Moore's law says that the on-chip
} TLB _will_ be big enough, that's just stupid).
What's the alternative for some PowerPC's? Every shared library program
likes to use the exact same addresses which load (and thus create htab
entries) at exactly the same location. A machine running 100+ processes is
not going to be usable because the every process is sharing the same 8 PTE
slots.
} But the whole point of _scattering_ is so incredibly broken in itself!
} Don't do it.
Yes, that is indeed correct theoretically. The problem is that we actually
measured it and there was very little locality. When I added some
multiple-tlb loads it actually decreased wall-clock performance for nearly
every user load I put on the machine. The common apps now-a-days are using
10's of shared libs so that would make it even worse.
} You can load many TLB entries in one go, if you just keep them close-by to
} each other. Load them into a prefetch-buffer (so that you don't dirty your
} real TLB with speculative TLB loads), and since there tends to be locality
} to TLB's, you've just automatically speeded up your hardware walker.
}
} In contrast, a hash algorithm automatically means that you cannot sanely
} do this _trivial_ optimization.
Linus, I knew that deep in my heart 8 years ago when I started in on all
this. I'm with you but I'm not good enough with a soldering iron to fix
every powerpc out there that forces that crappy IBM spawned madness upon
us.
I even wrote a paper about how bad a design is and how the designers should
be whipped for their foolish choices on the PPC. I'll hold the torch if
you knock on the castle door...
} Face it, hashes are BAD for things like this.
next prev parent reply other threads:[~2002-03-18 21:36 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-13 8:52 10.31 second kernel compile Anton Blanchard
2002-03-13 14:44 ` Martin J. Bligh
2002-03-13 21:44 ` [Lse-tech] " Dave Hansen
2002-03-14 1:07 ` Keith Owens
2002-03-14 11:27 ` Anton Blanchard
2002-03-14 13:16 ` [Lse-tech] " Dipankar Sarma
2002-03-17 13:12 ` some RCU dcache and ratcache results Anton Blanchard
2002-03-14 13:21 ` [Lse-tech] Re: 10.31 second kernel compile Momchil Velikov
2002-03-14 18:33 ` Daniel Phillips
2002-03-15 12:16 ` Chris Wedgwood
2002-03-16 5:12 ` Anton Blanchard
2002-03-15 18:20 ` Linus Torvalds
2002-03-16 11:55 ` Paul Mackerras
2002-03-16 17:25 ` Rik van Riel
2002-03-16 17:57 ` yodaiken
2002-03-16 18:06 ` Linus Torvalds
2002-03-16 18:35 ` yodaiken
2002-03-16 18:45 ` Linus Torvalds
2002-03-16 18:57 ` yodaiken
2002-03-16 19:16 ` Linus Torvalds
2002-03-16 19:43 ` David Mosberger
2002-03-16 19:58 ` Linus Torvalds
2002-03-16 20:08 ` yodaiken
2002-03-16 20:23 ` Linus Torvalds
2002-03-16 20:36 ` David Mosberger
2002-03-16 20:46 ` Linus Torvalds
2002-03-17 1:09 ` Paul Mackerras
2002-03-17 2:08 ` Linus Torvalds
2002-03-16 19:53 ` yodaiken
2002-03-16 20:02 ` Linus Torvalds
2002-03-16 20:25 ` yodaiken
2002-03-27 1:07 ` Richard Henderson
2002-03-16 20:53 ` Alan Cox
2002-03-18 3:07 ` David S. Miller
2002-03-16 15:24 ` Daniel Phillips
2002-03-16 19:01 ` Linus Torvalds
2002-03-16 22:25 ` Daniel Phillips
2002-03-19 16:35 ` Bill Davidsen
2002-03-14 19:05 ` Linus Torvalds
2002-03-19 16:40 ` Bill Davidsen
2002-03-14 18:21 ` Hanna Linder
2002-03-16 5:27 ` Anton Blanchard
2002-03-15 7:12 ` Chris Wedgwood
2002-03-16 6:15 ` 7.52 " Anton Blanchard
2002-03-16 6:42 ` [Lse-tech] " Gerrit Huizenga
2002-03-17 12:34 ` Anton Blanchard
2002-03-17 22:09 ` Theodore Tso
2002-03-18 7:04 ` Jeff Garzik
2002-03-19 18:28 ` Theodore Tso
2002-03-16 8:05 ` Linus Torvalds
2002-03-16 11:04 ` Paul Mackerras
2002-03-16 18:32 ` Linus Torvalds
2002-03-17 2:00 ` Paul Mackerras
2002-03-17 2:40 ` Linus Torvalds
2002-03-17 2:50 ` M. Edward Borasky
2002-03-18 15:08 ` 0.73 " snpe
2002-03-18 19:42 ` 7.52 " Cort Dougan
2002-03-18 20:04 ` Linus Torvalds
2002-03-18 20:23 ` Linus Torvalds
2002-03-18 21:50 ` Rene Herman
2002-03-18 22:36 ` Cort Dougan
2002-03-18 22:47 ` Linus Torvalds
2002-03-18 22:56 ` Cort Dougan
2002-03-18 23:52 ` Paul Mackerras
2002-03-19 0:57 ` Dave Jones
2002-03-19 3:35 ` Jeff Garzik
2002-03-19 0:22 ` David S. Miller
2002-03-19 0:27 ` Cort Dougan
2002-03-19 0:27 ` David S. Miller
2002-03-19 0:36 ` Cort Dougan
2002-03-19 0:38 ` David S. Miller
2002-03-19 1:28 ` Davide Libenzi
2002-03-19 2:42 ` Paul Mackerras
2002-03-27 2:53 ` Richard Henderson
2002-04-02 4:32 ` Linus Torvalds
2002-04-02 10:50 ` Pablo Alcaraz
2002-03-18 21:34 ` Cort Dougan [this message]
2002-03-18 22:00 ` Linus Torvalds
2002-03-18 19:37 ` Cort Dougan
2002-03-16 11:54 ` yodaiken
2002-03-16 17:37 ` [Lse-tech] " Martin J. Bligh
2002-03-16 18:57 ` Daniel Egger
2002-03-17 8:18 ` Mike Galbraith
2002-03-17 15:29 ` Martin J. Bligh
2002-03-17 1:45 ` Keith Owens
2002-03-17 13:54 ` David Woodhouse
2002-03-19 16:49 ` Bill Davidsen
-- strict thread matches above, loose matches on Subject: below --
2002-03-18 22:12 Dieter Nützel
2002-03-18 22:46 ` Linus Torvalds
2002-03-18 23:53 ` Davide Libenzi
2002-03-19 0:20 ` David S. Miller
2002-03-19 0:47 ` Davide Libenzi
2002-03-19 1:37 ` Andreas Ferber
2002-03-19 1:38 ` David S. Miller
2002-03-19 2:08 ` Linus Torvalds
2002-03-19 5:24 ` Erik Andersen
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=20020318143431.E4783@host110.fsmlabs.com \
--to=cort@fsmlabs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--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