[patch] zfs livelock and thread priorities

Attilio Rao attilio at freebsd.org
Mon May 18 17:38:06 UTC 2009

2009/5/18 John Baldwin <jhb at freebsd.org>:
> On Monday 18 May 2009 1:12:59 pm Attilio Rao wrote:
>> 2009/5/18 John Baldwin <jhb at freebsd.org>:
>> > On Saturday 16 May 2009 12:40:44 pm Ben Kelly wrote:
>> >>    1) 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.  I'm not sure how people feel about this.
>> >
>> > Actually, I almost think we should just add a priority argument to each of
> the
>> > routines that creates a new kthread/kproc.  Perhaps allow a priority of 0
> to
>> > let the thread run with the default priority.  Hmm, it looks like kthreads
>> > default to running with whatever thread0 runs at (PVM) which is probably
> not
>> > really ideal.  Having an explicit priority for every kthread would
> probably
>> > be best.  Most 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 threads
> and our ZFS doesn't set the priorities the same.  I think specifically there
> are "cleaner" threads which have a higher priority on Solaris than other ZFS
> threads and Solaris depends on that to avoid deadlocks.

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.  Right now all these threads start out with a priority
> of PVM since that is what thread0 runs at.  Does that sound right to you?  Do
> you think many folks realize that?  It sounds very bogus to me.  I 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.


Peace can only be achieved by understanding - A. Einstein

More information about the freebsd-current mailing list