linux-kernel - [PATCH] [DEBUG] sd-sched: monitor dynamic priority levels of a running task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <b647ffbd0704121615t1d201096u34bc975585985b57@mail.gmail.com>
Date:	Fri, 13 Apr 2007 01:15:34 +0200
From:	"Dmitry Adamushko" <dmitry.adamushko@...il.com>
To:	"Linux Kernel" <linux-kernel@...r.kernel.org>
Cc:	"Con Kolivas" <kernel@...ivas.org>, "ck list" <ck@....kolivas.org>
Subject: [PATCH] [DEBUG] sd-sched: monitor dynamic priority levels of a running task

Hi,

[ just in case, it can be of some avail for anybody ]

target : 2.6.21-rc6-mm1

a very simplified but quite funny "toy" that

[1]  allows to monitor all the dynamic priority levels (counts a
number of hits per level) on which a given task (configured via proc)
is running;

# echo "pid" > /proc/sd_pid  - to monitor a task with a given pid";
# cat /proc/sd_slots              - to dump statistics.

[2]  triggers a message when task's *prio* and *static_prio* are out
of sync, i.e. a current prio is not allowed by
prio_matrix[USER_PRIO(static_prio)].

[ example: --- [1857] static: 35, slot: 3  -  nice ]

maybe Con has something similar.. but at least I haven't found
anything on his website.

e.g. for X all the following scenarios give different (obviously)
patterns: (1) just occasional cpu users ; (2) a cpu hog with the same
static_prio; (3) a niced cpu hog.

There are cases when [2] is triggered indeed. It's due to
set_user_nice(). Con, is it a "feature"?

-------- [ explanation ] ---------
In fact, all this "delta" calculation (delta = p->prio - old_prio)
staff is useless in set_user_prio() as effective_prio() returns just
the old p->prio and, as a result, we have got p->prio = p->prio :)  It
makes sense to use delta = p->static_prio - old_static_prio;

The p->prio will be recalculated as a result of enqueue_task ->
__enqueue_task -> recalc_task_prio ..  _but_ if the task is currently
in the "active" array and its time_slice != 0 -- the old p->prio is
not changed

So the task is queued taking into account the old_prio, although this
slot can be prohibited by a new p->static_prio. It's only for the very
first slot so one may call it err.. a feature (?)
------------------------------------------------

-- 
Best regards,
Dmitry Adamushko

View attachment "sd-monitor_dyn_slots.patch" of type "text/x-patch" (4733 bytes)