Date: Mon, 18 May 2009 19:38:03 +0200 From: Attilio Rao <attilio@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Adam McDougall <mcdouga9@egr.msu.edu>, freebsd-current@freebsd.org, Artem Belevich <fbsdlist@src.cx>, Ben Kelly <ben@wanderview.com> Subject: Re: [patch] zfs livelock and thread priorities Message-ID: <3bbf2fe10905181038geaec26csffea4788a40feaca@mail.gmail.com> In-Reply-To: <200905181331.11174.jhb@freebsd.org> References: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <200905181129.51526.jhb@freebsd.org> <3bbf2fe10905181012t4bde260bp31181e3ea7b03a42@mail.gmail.com> <200905181331.11174.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/5/18 John Baldwin <jhb@freebsd.org>: > On Monday 18 May 2009 1:12:59 pm Attilio Rao wrote: >> 2009/5/18 John Baldwin <jhb@freebsd.org>: >> > On Saturday 16 May 2009 12:40:44 pm Ben Kelly wrote: >> >> =C2=A0 =C2=A01) It changes the kproc(9) API by adding a kproc_create_= priority() >> >> function that allows you to set the priority of the newly created >> >> thread. =C2=A0I'm not sure how people feel about this. >> > >> > Actually, I almost think we should just add a priority argument to eac= h of > the >> > routines that creates a new kthread/kproc. =C2=A0Perhaps allow a prior= ity of 0 > to >> > let the thread run with the default priority. =C2=A0Hmm, it looks like= kthreads >> > default to running with whatever thread0 runs at (PVM) which is probab= ly > not >> > really ideal. =C2=A0Having an explicit priority for every kthread woul= d > probably >> > be best. =C2=A0Most kthreads should probably be at PZERO by default I = think. >> >> I'm not sure I agree here. >> 1) Maybe I missed it (so please point me to the right one) but I >> didn't see a deep analysis of what messed up with the priorities there > > Solaris makes certain assumptions about the relative priorities of ZFS th= reads > and our ZFS doesn't set the priorities the same. =C2=A0I think specifical= ly there > are "cleaner" threads which have a higher priority on Solaris than other = ZFS > threads and Solaris depends on that to avoid deadlocks. OMG. This still doesn't explain priorities like 49 or such seen in the first report as long as we don't set priorities by hand, >> 2) I think this KPI can be dangerous and lead to problems. Priority is >> something highly fragile. > > All the more reason to make developers _think_ about the priority of each > kthread they create. =C2=A0Right now all these threads start out with a p= riority > of PVM since that is what thread0 runs at. =C2=A0Does that sound right to= you? =C2=A0Do > you think many folks realize that? =C2=A0It sounds very bogus to me. =C2= =A0I think > forcing people to pick a sensible priority for each thread is far better = than > the complete lack of thought that often happens now. At least, we could leave the default version not accepting any priority for threads which are not interested on that and trying to move people to the new KPI _only and if only_ they need real boosts or lay down. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10905181038geaec26csffea4788a40feaca>