Bug 141721 - rtprio(1): (id|rt)prio priority resets when new thread is created
Summary: rtprio(1): (id|rt)prio priority resets when new thread is created
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: threads (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-threads (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-17 19:20 UTC by c.kworr
Modified: 2018-01-03 05:13 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description c.kworr 2009-12-17 19:20:03 UTC
I'm just curious about this one.

I've got a big bunch mail and news on my home computer. On ZFS with
compression my mail profile weights 250Mb. I prefer to use seamonkey.
But sometimes after update seamonkey tries to compress mail folders
which can be huge. With 20 threads seamonkey effectively blocks my
computer from doing anything.

The simple solution I tried was idling seamonkey for 1 level with
idprio 1 -pid. But I was very surprised that one minute later top
shows that seamonkey has normal priority. Checking top continuously I
realiased that each time a new thread starts the priority resets to
normal. Running idprio 1 -pid again sets priority and I can see that
in top. But few moments later priority returns to normal again.

Fix: 

I'm not familiar with threading kernel code so I can't even imagine
where the problem is.
How-To-Repeat: Trying to run a program that creates threads with idprio and checking
the status of it would suffice.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2009-12-18 06:41:24 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-threads

Over to maintainer(s).
Comment 2 David Xu freebsd_committer 2010-09-30 18:48:05 UTC
idle priority is not supported by libthr yet, the reason I don't
want to enable it is kernel also may have trouble to handle idle
thread. a thread in kernel holds a non-mutex lock and is preempted,
it is possible to be starved by other threads, such a priority
reversal can make system work rather badly.

I think the thread preemption may should work in opposite direction.
default, it should always be disabled in kernel, only some
code knows where it is OK to be preempted:

1. interrupt thread preempt others
2. a thread returned to userland
3. some kernel code, it knows it is doing large computation,
    or non-sense code, it turns on preemption, when it exits
    such code, it turns off preemption.

idle thread does not mean it is not execute important code,
idle thread can execute any code in kernel, so idle does not
mean it is insignificant, the word 'idle' is bogus, priority
does not mean it is important or less important.
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:00 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped