All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Malek <dan@mvista.com>
To: paulus@linuxcare.com.au
Cc: Gabriel Paubert <paubert@iram.es>,
	tom_gall@vnet.ibm.com, linuxppc-commit@hq.fsmlabs.com,
	linuxppc-dev <linuxppc-dev@lists.linuxppc.org>
Subject: Re: context overflow
Date: Tue, 06 Feb 2001 16:32:57 -0500	[thread overview]
Message-ID: <3A806D89.16B31EA0@mvista.com> (raw)
In-Reply-To: 14975.55035.835724.234984@tango.linuxcare.com.au


Paul Mackerras wrote:

> What's incorrect about it?

The PowerPC gives us the ability to utilize a huge virtual address
space, and with newer processors a larger physical address space.
Although on 32-bit processors we can't see all of this at once, it
is there for us to use.  The only difference between a 32- and 64-bit
PowerPC kernel implementation is that on the 64-bit you get to see
all of the VM space all of the time, while the 32-bit system is
scurrying around behind the scenes ensuring what you need to see
is currently mapped.

We are currently using VSIDs as a lazy TLB reloader, not for
a large VM space context manager.  There shouldn't be any need
for CONFIG_HIGHMEM on PowerPC, and we should be able to map huge
PCI spaces we see on the multiple bridge CPCI systems without
any worry of running out of VM space.

The reason this is hard to realize today is we have built up a
system with the assumption there is only a 32-bit virtual space,
half of it consumed by a user task.  When I saw the VM changes
happening during 2.3, I saw hoping we could take the opportunity
to improve PowerPC performance with better MMU management.  Maybe
someday I can work on it.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2001-02-06 21:32 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-20  2:27 context overflow Dan Malek
2001-01-22  4:28 ` Troy Benjegerdes
2001-01-22  4:39   ` Tom Gall
2001-01-22 18:10     ` Dan Malek
2001-01-22 18:55     ` tom_gall
2001-01-22 19:59       ` Dan Malek
2001-01-22 22:08         ` tom_gall
2001-01-23  0:10           ` Dan Malek
2001-01-23 10:00             ` Gabriel Paubert
2001-01-23 18:21               ` Dan Malek
2001-02-06 10:55                 ` Paul Mackerras
2001-02-06 21:11                   ` Dan Malek
2001-02-06 21:50                     ` Paul Mackerras
2001-02-06 22:29                       ` Dan Malek
2001-02-06 22:45                         ` Paul Mackerras
2001-02-06 10:50               ` Paul Mackerras
2001-02-06 21:32                 ` Dan Malek [this message]
2001-02-06 22:08                   ` Paul Mackerras
2001-02-06 23:14                     ` Dan Malek
2001-02-07  0:23                       ` Paul Mackerras
2001-02-07 18:02                         ` Dan Malek
2001-02-08  0:48                           ` Paul Mackerras
2001-02-08  1:39                             ` Frank Rowand
2001-02-08 19:00                             ` David Edelsohn
2001-02-08 20:53                               ` Roman Zippel
2001-02-08 21:14                                 ` David Edelsohn
2001-02-08 23:23                                   ` Roman Zippel
2001-02-08 23:48                                     ` Cort Dougan
2001-02-08 21:28                               ` Cort Dougan
2001-02-08 22:08                                 ` David Edelsohn
2001-02-08 22:26                                   ` Cort Dougan
2001-02-08 23:17                                     ` David Edelsohn
2001-02-08 23:27                                       ` Cort Dougan
2001-02-08 23:28                                   ` Gabriel Paubert
2001-02-09  9:58                                     ` Paul Mackerras
2001-02-09 10:57                                       ` Gabriel Paubert
2001-02-09 11:26                                         ` Paul Mackerras
2001-02-09 10:49                               ` Paul Mackerras
2001-02-07  9:18                   ` Roman Zippel
2001-02-07 17:46                     ` Dan Malek
2001-02-07 18:39                       ` Roman Zippel
2001-02-07 21:16                         ` Gabriel Paubert
2001-02-08  0:34                           ` Paul Mackerras
2001-01-22  4:55   ` Larry McVoy
2001-01-22  6:15     ` Troy Benjegerdes
2001-01-23  1:12 ` Frank Rowand
2001-01-23  1:20   ` Dan Malek
2001-01-23  2:12     ` Frank Rowand

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=3A806D89.16B31EA0@mvista.com \
    --to=dan@mvista.com \
    --cc=linuxppc-commit@hq.fsmlabs.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=paubert@iram.es \
    --cc=paulus@linuxcare.com.au \
    --cc=tom_gall@vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.