linux-kernel - Re: [sched-devel, patch-rfc] rework of "prioritize non-migratabletasks over migratable ones"

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b647ffbd0806180458o6603adabgb80c88954981d47a@mail.gmail.com>
Date:	Wed, 18 Jun 2008 13:58:30 +0200
From:	"Dmitry Adamushko" <dmitry.adamushko@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Gregory Haskins" <ghaskins@...ell.com>,
	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	"Steven Rostedt" <rostedt@...dmis.org>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [sched-devel, patch-rfc] rework of "prioritize non-migratabletasks over migratable ones"

2008/6/18 Ingo Molnar <mingo@...e.hu>:
>
> * Gregory Haskins <ghaskins@...ell.com> wrote:
>
>> >>> On Mon, Jun 16, 2008 at  3:17 PM, in message
>> <1213643862.16944.142.camel@...ns>, Peter Zijlstra <a.p.zijlstra@...llo.nl>
>> wrote:
>> > On Mon, 2008-06-16 at 19:59 +0200, Dmitry Adamushko wrote:
>> >
>> >> One way or another, we have different aritifacts (and mine have likely
>> >> more) but conceptually, both "violates" POSIX if a strict round-robin
>> >> scheduling is required.
>> >
>> > http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_08.html#t
>> > ag_02_08_04_01
>> >
>> > Is quite strict on what FIFO should do, and I know of two points where
>> > we deviate and should work to match.
>>
>> Thanks for the link, Peter.  When you read that, its pretty clear that
>> this whole concept violates the standard.  Its probably best to just
>> revert the patch and be done with it.
>
> no, there's no spec violation here - the spec is silent on SMP issues.
>
> the spec should not be read to force a global runqueue for RT tasks.
> That would be silly beyond imagination.

I don't think it would actually make sense to specify behavior in
terms of per-cpu queues. This is an implementation detail. So the
_global_ (system-wise) queue makes more sense  (at least to me :-) if
one wants to define user-visible scheduling behavior.

e.g. as follows:
(http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_08.html#tag_02_08_04_01)

[quote]
"Threads scheduled under this policy are chosen from a thread list
that is ordered by the time its threads have been on the list without
being executed;"
[/quote]

>From the POV of users, I think only the "global" queue would make
sense. Otherwise, the sentence is rather useless.

[quote]
"generally, the head of the list is the thread that has been on the
list the longest time, and the tail is the thread that has been on the
list the shortest time."
[/quote]

OTOH, some differences can be justified by this "generally" word :-)

so it might be understood as something like this:

task_N can get a CPU only if all other pending runnable tasks that
have been enqueued earlier than task_N (of the same class and prio)
can _not_ start running on this CPU (e.g. due to their affinity).

Note, that our case is somewhat more subtle. We preempt a currently
running task in the hope that it can start running on another CPU
immediately, but we can't guarantee it.

Anyway, we are likely to win wrt cpu time distribution, but this fact
of 'preemption' is a new 'artifact' indeed.

if POSIX can be understood as : a SCHED_FIFO/RR task can be preempted
_only_ by a task with a higher prio and has to consume cpu-time as
long as it wants (FIFO) or till its timeslice expires (RR) , then we
violate it with this new behavior.

>
>        Ingo
>

-- 
Best regards,
Dmitry Adamushko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/