public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Cort Dougan <cort@fsmlabs.com>
To: Paul Mackerras <paulus@samba.org>
Cc: Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org
Subject: Re: 7.52 second kernel compile
Date: Mon, 18 Mar 2002 12:42:15 -0700	[thread overview]
Message-ID: <20020318124215.C4155@host110.fsmlabs.com> (raw)
In-Reply-To: <15507.9919.92453.811733@argo.ozlabs.ibm.com> <Pine.LNX.4.33.0203161020230.31850-100000@penguin.transmeta.com> <15507.63649.587641.538009@argo.ozlabs.ibm.com>

I have a counter-proposal.  How about a hardware tlb load (if we must have
one) that does the right thing?  I don't think the PPC is a good example of
a hardware well-managed TLB load process.  Software loads show up so well
on the PPC because it does some very very foolish things I suspect.  I've
had some conversations with Moto engineers who have suggested that my
suspicion that the TLB loads are actually cached when the hardware does
them so that we waste cache space with an line that we better darn well not
be loading again (otherwise we've thrown out our tlb way too early).

I still think there are some clever tricks one could do with the VSID's to
get a much saner system that the current hash table.  It would take some
serious work I think but the results could be worthwhile.  By carefully
choosing the VSID scatter algorithm and the size of the hash table I think
one could get a much better access method.

} However, one good argument against software TLB loading that I have
} heard (and which you mentioned in another message) is that loading a
} TLB entry in software requires taking an exception, which requires
} synchronizing the pipeline, which is expensive.  With hardware TLB
} reload you can just freeze the pipeline while the hardware does a
} couple of fetches from memory.  And PPC64 remains the only
} architecture I know of that supports a full 64-bit virtual address
} space _and_ can do hardware TLB reload.
} 
} I would be interested to see measurements of how many cache misses on
} average each hardware TLB reload takes; for a hash table I expect it
} would be about 1, for a 3-level tree I expect it would be very
} dependent on access pattern but I wouldn't be surprised if it averaged
} about 1 also on real workloads.
} 
} But this is all a bit academic, the real question is how do we deal
} most efficiently with the real hardware that is out there.  And if you
} want a 7.5 second kernel compile the only option currently available
} is a machine whose MMU uses a hash table. :)
} 
} Paul.
} -
} To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
} the body of a message to majordomo@vger.kernel.org
} More majordomo info at  http://vger.kernel.org/majordomo-info.html
} Please read the FAQ at  http://www.tux.org/lkml/

  parent reply	other threads:[~2002-03-18 19:45 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           ` Cort Dougan [this message]
2002-03-18 20:04             ` 7.52 " 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
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=20020318124215.C4155@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