headers
Toru Nishimura | 13 Jan 2003 03:27
Picon

Re: big endian hpcarm?

From: manu <at> netbsd.org (Emmanuel Dreyfus) asked;

[Big endian hpcarm]

>> Note that if you're using "hpcarm", you're talking about a system designed
>> to run WinCE, and thus is designed to be little-endian.
>
> You mean the hardware would not be able to run something else than a
> little endian OS?

If the entire hardware is designed _carefully_  to have no endianness issues
inside, the computer _might_ be capable of bi-endian.  Some CPU can be
re-programed to choose runtime endian at the very early stage of CPU self
initialization.  An external switch is mandated to do it.  At the same time, I'm
pretty suspicious WinCE devices are designed for bi-endian after all.  Say,
the OS itself is badly suffered from PC-ism and the hardware designers and
software programmers supposedly have little knowledge beyond Intel
processors.   They do sub-word load/store without hesitation.  They do
unaligned load/store across word boundary carelessly.  Indeed, there is LE
only MIPS processor in the world (by mistake of kitche engineers).

Toru Nishimura/ALKYL Technology
Permalink | Reply | 0 comments |
headers
Steve Woodford | 13 Jan 2003 13:14

Improving the arm32 pmap

Hi,

I'm sure this is something which has a number of people have toyed with
for quite some time now, with varying degrees of success.

As it happens, Wasabi have allocated a bunch of my time and given me the
resources to have a good crack at optimising the arm32 pmap, whether
through a wholesale re-write or just bending the existing code into shape.

I know some of you have already whacked on the pmap a bit, and Chris
Gilbert has already given me some of his experimental changes to look
over.

So, I'm soliciting opinions on what's wrong with the existing pmap, and
suggestions on either how to bend existing code into shape, or how to do
things differently/better with new code.

For example:

  Problem:
  - L1 page tables are "per process", and their allocation requires 16KB
    contig/aligned RAM. It's hard to allocate new L1 tables, given those
    constraints, which often leads to L1 starvation.
  - L1 page tables are also zeroed whenever they are allocated to a pmap.
    The kernel's descriptors are also copied over every time.

  Solutions:
  - Make use of the mmu's "domain" feature as a primitive form of ASID.
    This allows L1 tables to be shared between multiple pmaps by doing
    "lazy" fixup of user L1 entries at fault time.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Steve Woodford | 13 Jan 2003 21:06

Re: Improving the arm32 pmap

On Mon, 13 Jan 2003, Ignatios Souvatzis wrote:

> On Mon, Jan 13, 2003 at 12:14:17PM +0000, Steve Woodford
>
> <proposes to use arm mmu domains to share l1 page tables>
>
> For that, it was proposed that only pmaps without wired page entries should
> be candidates - however I don't know whether this is an absolute requirement
> or only an optimization. I suspect it would be a requirement for your method,
> too. Can somebody throw in some enlightment here?

Well, what I'm proposing would not, technically, be stealing the L1 page
tables. Think of it more as a form of TLB miss when we have to replace an
L1 descriptor when faulting due to a domain mismatch.

Cheers, Steve

--

-- 

Wasabi Systems Inc. - The NetBSD Company - http://www.wasabisystems.com/
Permalink | Reply | 2 comments |
headers
Ignatios Souvatzis | 13 Jan 2003 20:42
Picon

Re: Improving the arm32 pmap

Hi,

On Mon, Jan 13, 2003 at 12:14:17PM +0000, Steve Woodford

<proposes to use arm mmu domains to share l1 page tables>

Hm. Interesting idea. The other proposed solution would be to do l1 page
table stealing.

For that, it was proposed that only pmaps without wired page entries should
be candidates - however I don't know whether this is an absolute requirement
or only an optimization. I suspect it would be a requirement for your method,
too. Can somebody throw in some enlightment here?

Regards,
	-is
--

-- 
seal your e-mail: http://www.gnupg.org/
Permalink | Reply | 3 comments |
headers
Jason R Thorpe | 13 Jan 2003 21:41

Re: Improving the arm32 pmap

On Mon, Jan 13, 2003 at 12:14:17PM +0000, Steve Woodford wrote:

 > So, I'm soliciting opinions on what's wrong with the existing pmap, and
 > suggestions on either how to bend existing code into shape, or how to do
 > things differently/better with new code.

Off the top of my head:

	* Way way way too much I$ frobbing happens in the current pmap.
	  It seems as if in the current code, everytime the D$ is futzed
	  with, so is the I$.  This is a silly big-hammer approach, and
	  certainly could be optimized.

	  For user pmaps, I suggest a strategy like the one used by the
	  Alpha pmap.  That is, do not do ANY user I$ frobbing until the
	  actual return to userspace by a proc/lwp using that pmap.  A
	  side-effect is that you'd have to nail the entire I$ if the pmap
	  is marked as needing I$-sync, but that may still be faster.

	  (Note that with this strategy, you would still do any write-back
	  neccessary while in the kernel, just would skip the I$ flush part
	  of the step until userret().)

	  If it ends up not working out, at the very least the pmap needs
	  to be made more intelligent about when it actually needs to futz
	  with the I$.  Tracking exec permission in the PV entry would be
	  a good start.  (No exec'able mappings will ever be kenter'd, so
	  you don't need to worry about it there.)

	* Right now, the "PTPT" (the page table that maps the pmap's
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ignatios Souvatzis | 13 Jan 2003 22:02
Picon

Re: Improving the arm32 pmap

Hi,

On Mon, Jan 13, 2003 at 08:06:11PM +0000, Steve Woodford wrote:

> Well, what I'm proposing would not, technically, be stealing the L1 page
> tables. Think of it more as a form of TLB miss when we have to replace an
> L1 descriptor when faulting due to a domain mismatch.

But an entry in the victim L1 table wont be there any longer (and would have
to be recreated itself after a context switch back, if needed), right?

Regards,
	-is
--

-- 
seal your e-mail: http://www.gnupg.org/
Permalink | Reply | 0 comments |
headers
matthew green | 15 Jan 2003 08:26
Picon
Favicon

netwinder & mbr & bsdffs partition


hi folks.

i'm trying to install netbsd on a disk in a netwinder.  i have a disk
with 4 mbr partitions defined - linux, linux swap & netbsd, linux.
the last is a 10MB ext2fs partition used for booting (netwinder
"firmware" can read ext2fs).  the first is unused (and overlaps
other partitions).  when the machine boots, we get this from
"disklabel":

	8 partitions:
	#        size    offset     fstype  [fsize bsize cpg/sgs]
	 c:   8452080         0     unused      0     0         # (Cyl.    0 - 8943)
	 e:   4147542        63 Linux Ext2      0     0         # (Cyl.    0*- 4388)
	 f:    307200   8122200     unused      0     0         # (Cyl. 8594*- 8919)
	 g:   8122137        63     unused      0     0         # (Cyl.    0*- 8594*)
	 h:     22680   8429400 Linux Ext2      0     0         # (Cyl. 8920 - 8943)

i don't seem to be able to edit this disklabel any.  in particular,
i seem to be unable to create a BSDFFS partition i can use to install
netbsd on...

for now, i think i'm going to go for a patch to arm/arm/disksubr.c
to (a) convert linux swap partitions into (bsd) swap and (b) convert
"netbsd" partitions into "4.2BSD" partitions, but this is a hack (well
the swap thing might be a good thing to do but i don't really want
to think about that too much...) and certainly not something i'd want
to commit...

comments or suggestions?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ignatios Souvatzis | 24 Jan 2003 11:29
Picon
Favicon

Shouldn't we compile kernels at least without StrongARM optimizations?

Hi,

as all of you know, StrongARM optimized 1.6 compiled kernels tend to random
hangs.

Shouldn't we compile kernels without archv4 and strongarm optimizations 
until the compiler is fixed?

(I know the compiler has more problems - see for example PR 19276. But we
should at least make the kernel stable enough to _test_ the compiler.)

Regards,
	-is
Permalink | Reply | 5 comments |
headers
Richard Earnshaw | 24 Jan 2003 11:59
Favicon

Re: Shouldn't we compile kernels at least without StrongARM optimizations?

> Hi,
> 
> as all of you know, StrongARM optimized 1.6 compiled kernels tend to random
> hangs.
> 

Well I wasn't aware of that (though I'm running current rather than 1.6).  
Where's the relevant PR?

> Shouldn't we compile kernels without archv4 and strongarm optimizations 
> until the compiler is fixed?

How do you know it's the compiler?  If it's a random behaviour, then my 
first suspicion would be that it's some sort of timing issue (or cache 
related).  Compiler errors generally lead to repeatable problems.  There 
was a lot of hacking on the pmap in the run up to 1.6, and it wouldn't 
surprise me in the least if that wasn't the cause of your problems.

R.
Permalink | Reply | 4 comments |
headers
Ignatios Souvatzis | 24 Jan 2003 12:17
Picon
Favicon

Re: Shouldn't we compile kernels at least without StrongARM optimizations?

hi,

On Fri, Jan 24, 2003 at 10:59:36AM +0000, Richard Earnshaw wrote:
> > Hi,
> > 
> > as all of you know, StrongARM optimized 1.6 compiled kernels tend to random
> > hangs.
> > 
> 
> Well I wasn't aware of that (though I'm running current rather than 1.6).  
> Where's the relevant PR?

When I mumbled on ICB about hangs, I immediately got the advice to compile
without strongarm optimization, that's why I assumed it was generally known.

I opened a PR: port-shark/20027

> > Shouldn't we compile kernels without archv4 and strongarm optimizations 
> > until the compiler is fixed?
> 
> How do you know it's the compiler?

I don't know. I was pointed to it. Alas, I don't remember anymore by whom.

> If it's a random behaviour, then my 
> first suspicion would be that it's some sort of timing issue (or cache 
> related).  Compiler errors generally lead to repeatable problems.  There 
> was a lot of hacking on the pmap in the run up to 1.6, and it wouldn't 
> surprise me in the least if that wasn't the cause of your problems.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane