linux-kernel - Re: RFC for a new Scheduling policy/class in the Linux-kernel

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090715231646.GI14993@cs.fsu.edu>
Date:	Wed, 15 Jul 2009 19:16:46 -0400
From:	Ted Baker <baker@...fsu.edu>
To:	Dhaval Giani <dhaval.giani@...il.com>
Cc:	Chris Friesen <cfriesen@...tel.com>,
	"James H. Anderson" <anderson@...unc.edu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Raistlin <raistlin@...ux.it>,
	Douglas Niehaus <niehaus@...c.ku.edu>,
	Henrik Austad <henrik@...tad.us>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Bill Huey <billh@...ppy.monkey.org>,
	Linux RT <linux-rt-users@...r.kernel.org>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	Thomas Gleixner <tglx@...utronix.de>,
	Noah Watkins <jayhawk@....ucsc.edu>,
	KUSP Google Group <kusp@...glegroups.com>,
	Tommaso Cucinotta <cucinotta@...up.it>,
	Giuseppe Lipari <lipari@...is.sssup.it>,
	Bjoern Brandenburg <bbb@...unc.edu>
Subject: Re: RFC for a new Scheduling policy/class in the Linux-kernel

> > 1) The priority of a group seemed to be defined by the priority of
> > the highest-priority thread in the group's run-queue, which means
> > it varies dynamically according to which threads in the group are
> > contending.
> >
> 
> This is true, but it also ensures that the time allocated to the group
> is also consumed by group if it wants to.

I don't see how schedulability analysis can be done with this model,
since a single budget is being expended at varying priorities/deadlines.

> > 4) On an SMP, more than one thread could be running against
> > the same budget at the same time, resulting in budget over-charges.
> >
> 
> The rt group scheduler does split the budget per cpu. On expiring the
> budget, it tries to borrow from other CPUs if possible.

First, how is the splitting of the budget between CPU's controlled
by the application?

Second, I don't see how schedulabiliyt analysis could be done if
CPU's can "borrow" budget from other CPUs, unless there is some
mechanism in place to "pay it back".  How do you do the analysis?

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