On Mon, Jul 08, 2024 at 02:22:51PM +0200, Claudio Jeker wrote:
> On Mon, Jul 08, 2024 at 01:21:47PM +0200, Martin Pieuchot wrote:
> > I'd like to start simplifying the existing scheduler.  Diff below
> > introduces a function to unpeg curproc from its current CPU.  This
> > will be required as soon as we no longer rely on per-CPU runqueues
> > to implement thread pegging.
> > 
> > ok?
> > 


> > @@ -625,6 +625,8 @@ sched_peg_curproc(struct cpu_info *ci)
> >  {
> >  	struct proc *p = curproc;
> >  
> > +	KASSERT(!ISSET(p->p_flag, P_CPUPEG));
> > +

Missed this before. I think this is not good. We need to be able to peg
procs from one CPU to another CPU without unpegging them first.

> > @@ -162,8 +162,8 @@ smr_grace_wait(void)
> >  			continue;
> >  		sched_peg_curproc(ci);
> >  		KASSERT(ci->ci_schedstate.spc_smrgp == smrgp);
> > +		sched_unpeg_curproc();
> >  	}
> > -	atomic_clearbits_int(&curproc->p_flag, P_CPUPEG);
> 
> Can we move the sched_unpeg_curproc() out of the loop here (where the
> atomic op is)?
> 
> In other words will the new API allow calls to sched_peg_curproc() to
> switch cpus or do we need to unpeg before?
> e.g.
> 	sched_peg_curproc(cpu1);
> 	/* do something on cpu1 */
> 	sched_peg_curproc(cpu2);
> 	/* do something else on cpu2 */
> 
> Or do we really need to unpeg before repegging?
> If that is the case then I think this diff is not correct.

-- 
:wq Claudio