linux-kernel - Re: -rt more realtime scheduling issues

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, 8 Oct 2007 11:45:23 -0700
From:	Mike Kravetz <kravetz@...ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: -rt more realtime scheduling issues

On Fri, Oct 05, 2007 at 07:15:48PM -0700, Mike Kravetz wrote:
> After applying the fix to try_to_wake_up() I was still seeing some large
> latencies for realtime tasks.

I've been looking for places in the code where reschedule IPIs should
be sent in the case of 'overload' to redistribute RealTime tasks based
on priority.  However, an even more basic question to ask might be:  Are
the use of reschedule IPIs reliable enough for this purpose.  In the
code, there is the following comment:

/*
 * this function sends a 'reschedule' IPI to another CPU.
 * it goes straight through and wastes no time serializing
 * anything. Worst case is that we lose a reschedule ...
 */

After a quick read of the code, it does appear that reschedule's can
be lost if the the IPI is sent at just the right time in schedule
processing.  Can someone confirm this is actually the case?

The issue I see is that the 'rt_overload' mechanism depends on reschedule
IPIs for RealTime scheduling semantics.  If this is not a reliable
mechanism then this can lead to breakdowns in RealTime scheduling semantics.

Are these accurate statements?  I'll start working on a reliable delivery
mechanism for RealTime scheduling.  But, I just want to make sure that
is really necessary.

-- 
Mike
-
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/