From owner-freebsd-threads@FreeBSD.ORG Sat May 1 09:09:20 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64E3F16A4CE for ; Sat, 1 May 2004 09:09:20 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E88B843D49 for ; Sat, 1 May 2004 09:09:19 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i41G9JS8017036; Sat, 1 May 2004 12:09:19 -0400 (EDT) Date: Sat, 1 May 2004 12:09:19 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Petri Helenius In-Reply-To: <4093C611.40600@he.iki.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-threads@freebsd.org Subject: Re: system priorities X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2004 16:09:20 -0000 On Sat, 1 May 2004, Petri Helenius wrote: > Daniel Eischen wrote: >=20 > >>This sounds like a bug. Could it change the KSEG which called the rtpri= o=20 > >>so there would be some deterministic behaviour to the rtprio if used in= =20 > >>threaded program? So I take it from this that rtprio is also broken for= =20 > >>libthr? > >> =20 > >> > > > >Yes. > > > > =20 > > > Can and should it be fixed? Index: kern/kern_resource.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /opt/FreeBSD/cvs/src/sys/kern/kern_resource.c,v retrieving revision 1.136 diff -u -r1.136 kern_resource.c --- kern/kern_resource.c=0910 Apr 2004 11:08:16 -0000=091.136 +++ kern/kern_resource.c=091 May 2004 14:00:37 -0000 @@ -318,6 +318,7 @@ { =09struct proc *curp; =09register struct proc *p; +=09struct ksegrp *kg; =09struct rtprio rtp; =09int cierror, error; =20 @@ -328,6 +329,7 @@ =09=09cierror =3D 0; =20 =09curp =3D td->td_proc; +=09kg =3D td->td_ksegrp; =09if (uap->pid =3D=3D 0) { =09=09p =3D curp; =09=09PROC_LOCK(p); @@ -342,7 +344,7 @@ =09=09if ((error =3D p_cansee(td, p))) =09=09=09break; =09=09mtx_lock_spin(&sched_lock); -=09=09pri_to_rtp(FIRST_KSEGRP_IN_PROC(p), &rtp); +=09=09pri_to_rtp(kg, &rtp); =09=09mtx_unlock_spin(&sched_lock); =09=09PROC_UNLOCK(p); =09=09return (copyout(&rtp, uap->rtp, sizeof(struct rtprio))); @@ -373,7 +375,7 @@ =09=09=09} =09=09} =09=09mtx_lock_spin(&sched_lock); -=09=09error =3D rtp_to_pri(&rtp, FIRST_KSEGRP_IN_PROC(p)); +=09=09error =3D rtp_to_pri(&rtp, kg); =09=09mtx_unlock_spin(&sched_lock); =09=09break; =09default: Index: kern/kern_thread.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /opt/FreeBSD/cvs/src/sys/kern/kern_thread.c,v retrieving revision 1.176 diff -u -r1.176 kern_thread.c --- kern/kern_thread.c=0928 Apr 2004 20:36:53 -0000=091.176 +++ kern/kern_thread.c=091 May 2004 14:06:50 -0000 @@ -337,7 +337,7 @@ =09kg->kg_numupcalls =3D 0; =09/* link it in now that it's consistent */ =09p->p_numksegrps++; -=09TAILQ_INSERT_HEAD(&p->p_ksegrps, kg, kg_ksegrp); +=09TAILQ_INSERT_TAIL(&p->p_ksegrps, kg, kg_ksegrp); } =20 void > > > >The Solaris priocntl() lets you set/get: > > > > P_LWPID > > The id argument is an LWP ID. The priocntl function > > applies to the LWP with the specified ID within the > > calling process. > > > > =20 > > > Where would I get the "P_LWPID"? I=B4m not sure it's a good idea to expos= e=20 > the kse structure to an application using pthreads. There would be a way to get it, but you needn't if you use P_MYID. Solaris has _lwp_self(). One of the other things on my wish list is to be able to bind (soft affinity) KSEs to processors. --=20 Dan Eischen