linux-kernel - Re: [(RT RFC) PATCH v2 1/9] allow rt-mutex lock-stealing to includelateral priority

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]

Date:	Mon, 3 Mar 2008 10:55:09 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Gregory Haskins <ghaskins@...ell.com>
cc:	a.p.zijlstra@...llo.nl, mingo@...e.hu, bill.huey@...il.com,
	kevin@...man.org, tglx@...utronix.de, cminyard@...sta.com,
	dsingleton@...sta.com, dwalker@...sta.com,
	Moiz Kohari <MKohari@...ell.com>,
	Peter Morreale <PMorreale@...ell.com>,
	Sven Dietrich <SDietrich@...ell.com>, dsaxena@...xity.net,
	acme@...hat.com, ak@...e.de, gregkh@...e.de, npiggin@...e.de,
	pavel@....cz, linux-kernel@...r.kernel.org,
	linux-rt-users@...r.kernel.org
Subject: Re: [(RT RFC) PATCH v2 1/9] allow rt-mutex lock-stealing to
 includelateral priority


On Mon, 3 Mar 2008, Gregory Haskins wrote:

> >>> On Mon, Mar 3, 2008 at 10:13 AM, in message
> >
> > See the issue. The RT task on CPU0 may experience huge latencies.
>
> Agreed, but equal priority threads can always cause unbounded latencies by definition.  I.e. we only guarantee to the highest thread.

It should not when they are bounded to two separate CPUs, and are the
highest priority tasks on those CPUS.  That will be hard to explain, how a
the highest prio tasks bounded to a single CPU had an unbounded latency.
With the patches presented, this can happen.

>
> > Remember, RT is worried about latencies over performance.
> > If we can not ***guarantee*** a bounded latency, then, I don't care
> > how good the perfomance is, it is not good enough for RT.
> >
> >
> > That said, here's the compromise.
> >
> > Non-RT tasks care more about overall perfomance than worst case latencies.
> > So.... See imbedded:
>
> This isn't a bad idea, but note that it means RT tasks will not get a performance boost, which is quite substantial.

Again, no performance is good enough for an RT task if it risks the
slightest chance of causing an unbounded latency.

-- Steve

>
> Note that I have substantially cleaned up this patch for the drop I will make later this week (v3).
--
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/