Date: Mon, 18 May 2009 22:12:58 -0400 From: Ben Kelly <ben@wanderview.com> To: Attilio Rao <attilio@freebsd.org> Cc: Adam McDougall <mcdouga9@egr.msu.edu>, freebsd-current@freebsd.org, Artem Belevich <fbsdlist@src.cx> Subject: Re: [patch] zfs livelock and thread priorities Message-ID: <34451C28-9ADF-467B-B2C8-43498C87C0C2@wanderview.com> In-Reply-To: <3bbf2fe10905181038geaec26csffea4788a40feaca@mail.gmail.com> References: <08D7DC2A-68BE-47B6-8D5D-5DE6B48F87E5@wanderview.com> <200905181129.51526.jhb@freebsd.org> <3bbf2fe10905181012t4bde260bp31181e3ea7b03a42@mail.gmail.com> <200905181331.11174.jhb@freebsd.org> <3bbf2fe10905181038geaec26csffea4788a40feaca@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 18, 2009, at 1:38 PM, Attilio Rao wrote:
> 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,
I'm trying to understand why this particular priority value is so
concerning, but I'm a little bit confused. Can you elaborate on why
you think its a problem? From previous off-list e-mails I get the
impression that you are concerned that it does not fall on an RQ_PPQ
boundary. Is this the case? Again, I may be completely confused, but
ULE does not seem to consider RQ_PPQ when it assigns priorities for
interactive threads. Here is how I came to this conclusion:
From what I can tell a thread's priority might be adjusted for
interactivity in sched_priority() around line 1421 of sched_ule:
> score = imax(0, sched_interact_score(td) - td->td_proc-
> >p_nice);
> if (score < sched_interact) {
> pri = PRI_MIN_REALTIME;
> pri += ((PRI_MAX_REALTIME - PRI_MIN_REALTIME) /
> sched_interact)
> * score;
One my machine (PRI_MAX_REALTIME - PRI_MIN_REALTIME) / sched_interact
resolves to a value of 1. So the priority is being set to
PRI_MIN_REALTIME plus the value of score. According to the comment on
sched_interact_score() the returned value ranges from 0 to 100. As
far as I can tell from looking at the code the calculations based on
the ration of ts_runtime to ts_sleeptime aren't guaranteed to return a
value divisible by RQ_PPQ. For example, on my machine tickincr turns
out to be 8000. So if ts_sleeptime is 16000 and ts_runtime is 8000
sched_interact_score() will return a value of 25. Which then means
the thread will be assigned a priority of PRI_MIN_REALTIME + 25.
Also, looking at my currently idle system I actually have many
priorities that do not fall on RQ_PPQ boundaries:
> ianto# ps ax -opri | grep 43 | wc -l
> 14
> ianto# ps ax -opri | grep 44 | wc -l
> 70
> ianto# ps ax -opri | grep 45 | wc -l
> 4
> ianto# ps ax -opri | grep 46 | wc -l
> 3
> ianto# ps ax -opri | grep 47 | wc -l
> 2
> ianto# ps ax -opri | grep 48 | wc -l
> 1
> ianto# ps ax -opri | grep 49 | wc -l
> 1
I'm running a non-SMP kernel with ULE last synced with subversion on
March 16. Full system info can be found here:
http://www.wanderview.com/svn/public/misc/zfs_livelock/
Anyway, I apologize if I'm missing something. I'd be happy to do more
investigation if you'd like. Just let me know.
Thanks!
- Ben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34451C28-9ADF-467B-B2C8-43498C87C0C2>