Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-Id: <20190726145409.947503076@infradead.org>
User-Agent: quilt/0.65
Date:   Fri, 26 Jul 2019 16:54:09 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     mingo@kernel.org, juri.lelli@redhat.com
Cc:     linux-kernel@vger.kernel.org, dietmar.eggemann@arm.com,
        luca.abeni@santannapisa.it, bristot@redhat.com,
        balsini@android.com, dvyukov@google.com, tglx@linutronix.de,
        vpillai@digitalocean.com, rostedt@goodmis.org, peterz@infradead.org
Subject: [RFC][PATCH 00/13] SCHED_DEADLINE server infrastructure
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

So recently syzcaller ran into the big deadline/period issue (again), and I
figured I should at least propose a patch that puts limits on that -- see Patch 1.

During that discussion; SCHED_OTHER servers got mentioned (also again), and I
figured I should have a poke at that too. So I took some inspiration from
patches Alessio Balsini send a while back and cobbled something together for
that too.

Included are also a bunch of patches I did for core scheduling (2-8),
which I'm probably going to just merge as they're generic cleanups.
They're included here because they make pick_next_task() simpler and
thereby thinking about the nested pick_next_task() logic inherent in
servers was less of a head-ache. (I think it can work fine without them,
but its easier with them on)

Anyway; after it all compiled it booted a kvm image all the way to userspace on
the first run, so clearly this code isn't to be trusted at all.

There's still lots of missing bits and pieces -- like changelogs and the
fair server isn't configurable or hooked into the bandwidth accounting,
but the foundation is there I think.

Enjoy!