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