Re: CVS commit: src/sys/arch/sparc/sparc

2020-03-15 Thread Andrew Doran 
On Sun, Mar 15, 2020 at 11:38:03AM +1100, matthew green wrote:
> "Andrew Doran" writes:
> > Module Name:src
> > Committed By:   ad
> > Date:   Sat Mar 14 13:34:44 UTC 2020
> > 
> > Modified Files:
> > src/sys/arch/sparc/sparc: intr.c
> > 
> > Log Message:
> > sparc cpu_intr_p(): try to work around l_cpu not being set early on by
> > using curcpu().
> 
> ah, good idea.  this will involve one fewer deref, curcpu()
> is mapped at a fixed address, so it might even be faster now
> than it used to be.

Oh, hm..  Given that it's a fixed address is there a way the compiler can
screw this up in the face of a kernel preemption (theoretical right now for
sparc*)?  I don't think so..  None of the fanciness is required then.

bool
cpu_intr_p(void)
{

return curcpu()->ci_idepth != 0;
}

Andrew

re: CVS commit: src/sys/arch/sparc/sparc

2020-03-14 Thread matthew green 
"Andrew Doran" writes:
> Module Name:  src
> Committed By: ad
> Date: Sat Mar 14 13:34:44 UTC 2020
> 
> Modified Files:
>   src/sys/arch/sparc/sparc: intr.c
> 
> Log Message:
> sparc cpu_intr_p(): try to work around l_cpu not being set early on by
> using curcpu().

ah, good idea.  this will involve one fewer deref, curcpu()
is mapped at a fixed address, so it might even be faster now
than it used to be.


.mrg.

re: CVS commit: src/sys/arch/sparc/sparc

2018-01-16 Thread matthew green 
"Christos Zoulas" writes:
> Module Name:  src
> Committed By: christos
> Date: Wed Jan 17 02:39:16 UTC 2018
> 
> Modified Files:
>   src/sys/arch/sparc/sparc: cpuvar.h
> 
> Log Message:
> fix compilation

actually, this was renamed and moved, so this is also wrong.
i'll fix it.


.mrg.

Re: CVS commit: src/sys/arch/sparc/sparc

2012-11-04 Thread Chuck Silvers 
On Sun, Nov 04, 2012 at 01:35:04PM +1100, matthew green wrote:
 
  Module Name:src
  Committed By:   chs
  Date:   Sun Nov  4 00:32:47 UTC 2012
  
  Modified Files:
  src/sys/arch/sparc/sparc: locore.s pmap.c
  
  Log Message:
  in cpu_switchto(), remove the MP-unsafe code to mark a pmap active on a CPU,
  pmap_activate() already does this.  add MP locking to pmap_activate()
  and pmap_deactivate().  move flushing of user windows and virtual caches
  from pamp_activate() to pmap_deactivate().
 
 
 hmm.  this makes pmap_deactivate() do things in UP that weren't being
 done before at all.  switching to/from kernel/lwp for the same lwp will
 now be flushing the ctx every time.  that seems suboptimal?

do you just mean that I should have left the #ifdef MULTIPROCESSOR
around the sp_tlb_flush()?  or something more than that?


 we should really update PMAP_LOCK() to not be kernel lock.

agreed.

beyond that, there's still plenty of room for improvement on most platforms.
I think the best example in our tree at this point is the x86 scheme
of deferring the MMU-switch work to points where we're actually about to
reference user mappings, eg. returning to user mode, copyin/copyout, etc.


-Chuck

re: CVS commit: src/sys/arch/sparc/sparc

2012-11-03 Thread matthew green 

 Module Name:  src
 Committed By: chs
 Date: Sun Nov  4 00:32:47 UTC 2012
 
 Modified Files:
   src/sys/arch/sparc/sparc: locore.s pmap.c
 
 Log Message:
 in cpu_switchto(), remove the MP-unsafe code to mark a pmap active on a CPU,
 pmap_activate() already does this.  add MP locking to pmap_activate()
 and pmap_deactivate().  move flushing of user windows and virtual caches
 from pamp_activate() to pmap_deactivate().


hmm.  this makes pmap_deactivate() do things in UP that weren't being
done before at all.  switching to/from kernel/lwp for the same lwp will
now be flushing the ctx every time.  that seems suboptimal?

we should really update PMAP_LOCK() to not be kernel lock.


.mrg.

re: CVS commit: src/sys/arch/sparc/sparc

2011-09-06 Thread matthew green 

 Module Name:  src
 Committed By: martin
 Date: Thu Sep  1 08:47:56 UTC 2011
 
 Modified Files:
   src/sys/arch/sparc/sparc: pmap.c
 
 Log Message:
 In pmap_unwire() fix an obvious editor mishap - enable kernel preemption
 before returning, not the other way around.
 Might fix PR kern/45137.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.345 -r1.346 src/sys/arch/sparc/sparc/pmap.c

thanks for fixing this.

hmm... code was like:

{
return;
foo();
}

it would be nice if we got warnings about this.


.mrg.

Re: CVS commit: src/sys/arch/sparc/sparc

2009-05-27 Thread Valeriy E. Ushakov 
On Wed, May 27, 2009 at 04:08:06 +, matthew green wrote:

 Modified Files:
   src/sys/arch/sparc/sparc: vm_machdep.c
 
 Log Message:
 sync this a little with sparc64: use cpu_setfunc() at the end of 
 cpu_lwp_fork()
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.98 -r1.99 src/sys/arch/sparc/sparc/vm_machdep.c

Is that correct?  It used to be in 4.0, but in 5.0 lwp trampoline
calls lwp_startup before calling the lwp function.  For SA the
trampoline used to be used for recycling lwps for upcalls.  Is that
correct to call lwp_startup in that case?  There never was any
official note on that when SA became undead.

SY, Uwe
-- 
u...@stderr.spb.ru   |   Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/  |   Ist zu Grunde gehen

re: CVS commit: src/sys/arch/sparc/sparc

2009-05-16 Thread matthew green 

   Module Name: src
   Committed By:cegger
   Date:Sat May 16 17:01:16 UTC 2009
   
   Modified Files:
src/sys/arch/sparc/sparc: machdep.c process_machdep.c svr4_machdep.c
vm_machdep.c
   
   Log Message:
   KNF, same object code generated.


why are you doing this?  are you planning on touching all of these
files or are you doing a KNF rototill that you shouldn't?


.mrg.

Re: CVS commit: src/sys/arch/sparc/sparc

2009-05-16 Thread Izumi Tsutsui 
Modified Files:
   src/sys/arch/sparc/sparc: machdep.c process_machdep.c svr4_machdep.c
   vm_machdep.c

Log Message:
KNF, same object code generated.
 
 
 why are you doing this?  are you planning on touching all of these
 files or are you doing a KNF rototill that you shouldn't?

The log message should be:
remove extra whitespace accidentally added on bcopy - memcpy changes

---
Izumi Tsutsui