Subject: effecient context switches on the StrongArm

From: "Adam 'WeirdArms' Wiggins" <[email-masked]>
Date: Tue, 6 Oct 1998 18:10:43 +1000 (EST)

I think this might have come up before but i'm looking at doing
some OS design for the StrongArm SA1100. The virtually taged caches are
looking at being a bit of a problem for context switches. Has anyone come
up with any idea's for cutting back the cost of context switches on the
StrongArm? Perhaps using domains or something?
	I'd appriciate anyones idea or pointers to papers on the subject.

	Cheers Adam

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Matthew Wilcox <[email-masked]>
Date: Tue, 6 Oct 1998 11:49:45 +0200

> 	I'd appriciate anyones idea or pointers to papers on the subject.

I have a paper on the subject, not to hand right now.  It was implemented
on the HP-PA RISC with the Mach `micro'kernel.  The authors show some
interesting results; and I've been thinking about doing this for ARMLinux.
Basically, they delay purge/flush operations till they have to be done,
frequently with the reult that they don't need to be done.  I'm not
entirely convinced this will work well on the SA, but I'll get you the
reference of the paper tomorrow.

-- 
Matthew Wilcox <[email-masked]>
"I decry the current tendency to seek patents on algorithms.  There are
better ways to earn a living than to prevent other people from making use of
one's contributions to computer science."  -- Donald E. Knuth, TAoCP vol 3
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Tue, 06 Oct 1998 11:07:27 +0100

>	I'd appriciate anyones idea or pointers to papers on the subject.

As you've noticed it's a bit of a nuisance that you have to flush the cache on 
every context switch to get rid of outdated mappings.  You could try to 
amortise this by marking dirty data pages as inaccessible on a switch so that 
accesses will trap, and flushing them one at a time.  For processes with a 
small working set this might work fairly well but for larger programs (gcc) it 
would almost certainly be a serious loss.  To find out which pages were 
dirty you'd have to initially write protect them all and again trap accesses.

If you're resigned to the idea of doing a complete cache flush on every switch 
then you could consider doing the flush by reading in data from the new task's 
address space (maybe its stack) so that at least you have a sporting chance of 
warming the cache with data that will be useful.  The flip side to that is 
that particularly on the 1100 it will be slower than using the dedicated cache 
flush area.

There may be some literature around on the subject; the ARM family isn't 
(quite) the only series of processors with virtual-tagged caches. 

p.

---

From: Alan Cox <[email-masked]>
Date: Tue, 6 Oct 1998 12:22:06 +0100 (BST)

> (quite) the only series of processors with virtual-tagged caches. 

The obvious literature item:

	"Unix systems for modern architectures" - Curt Schimmel

---

From: "Neil A. Carson" <[email-masked]>
Date: Tue, 06 Oct 1998 12:29:35 +0100

>         I'd appriciate anyones idea or pointers to papers on the subject.

Don't use address aliasing.

	Neil

-- 
Neil A. Carson

---

From: "Neil A. Carson" <[email-masked]>
Date: Tue, 06 Oct 1998 12:31:23 +0100

> interesting results; and I've been thinking about doing this for ARMLinux.

I've already implemented this for NetBSD...

> reference of the paper tomorrow.

...Unfortunately the MIPS and the ARM are quite different.
Unfortunately, in the terms of a context switch the ops can't really be
delayed, but on some other MMU ops can. the MIPS tags cache lines by PID
as well as address.

	Neil

-- 
Neil A. Carson

---

From: Alan Cox <[email-masked]>
Date: Tue, 6 Oct 1998 18:41:37 +0100 (BST)

> Don't use address aliasing.

Nice if you can avoid it. But for unixlike OS's not only do you get
inter process aliasing you get CPU local aliasing. Try mapping the
same sys5 shm block into two places in the same process.

That one is ugly as hell even with tagged caches like the sparc.
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Tue, 6 Oct 1998 22:21:50 +0100 (BST)

> dirty you'd have to initially write protect them all and again trap accesses.

There are other advantages that I can see from getting Linux to delay cache
flushing/tlb flushing on context switching.  I'm considering about a few
additional optimisations which delayed cache flushing will allow which could
increase performance (both context switching and IO performance).  However,
I'd like to think about them for a little longer before making them public.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.uk.linux.org/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]