Re: CVS commit: src/sys/arch/sparc/sparc
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
"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
"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
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
> 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
> 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
On Wed, May 27, 2009 at 01:35:49PM +0400, Valeriy E. Ushakov wrote: > 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. Good catch - lwp_startup() should only be called at "lwp birth time" (according to Andrew) - we need to review all ports and split the trampolines used. Martin
Re: CVS commit: src/sys/arch/sparc/sparc
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
>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" ah, thanks! .mrg.
Re: CVS commit: src/sys/arch/sparc/sparc
>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
re: CVS commit: src/sys/arch/sparc/sparc
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.
