Subject: Re: deadlock with sched_lock in SA code
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Chuck Silvers <chuq@chuq.com>
List: tech-kern
Date: 10/05/2005 08:41:38
On Tue, Sep 20, 2005 at 08:00:50PM +0900, YAMAMOTO Takashi wrote:
> > > Maybe we could free it to a private free list, and when upcalls are  
> > > allocated, we can just check the free list before calling pool_get 
> > > ().  That way we could actually use the straggler.
> > 
> > we could, but that would need either an extra lock, or some dance with
> > sched_lock if we would try to protect it with that, or some per-CPU list.
> > it doesn't seem worth the complexity.
> 
> i don't think it's so complex.
> holding a single sau should be enough.
> 
> in ltsleep:
> 	if (curcpu()->ci_data.ci_sau == NULL) {
> 		curcpu()->ci_data.ci_sau = sadata_upcall_alloc(0);
> 	}
> 
> in sa_switch:
> 	instead of sadata_upcall_alloc:
> 		sau = curcpu()->ci_data.ci_sau;
> 		curcpu()->ci_data.ci_sau = NULL;
> 
> 	instead of sadata_upcall_free:
> 		curcpu()->ci_data.ci_sau = sau;
> 
> ideally, sa lwp cache can be per-cpu as well, i think.

hmm, I think you're right that one would be enough and we don't need a list.
I'm not thrilled about having this kind of silly stuff in the cpuinfo though.

for now I checked in the previous version, we can come back to this later
if you want.

-Chuck