linux-kernel - Re: [RFC] dynsched - different cpu schedulers per cpuset

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

Date:	Thu, 30 Nov 2006 20:40:24 +0100
From:	Felix Obenhuber <felix@...nhuber.de>
To:	Paul Menage <menage@...gle.com>
Cc:	Paul Jackson <pj@....com>, linux-kernel@...r.kernel.org,
	dynsched-devel@...ts.sourceforge.net
Subject: Re: [RFC] dynsched - different cpu schedulers per cpuset

> Possibly, if it was some kind of multi-level scheduler - i.e. a
> top-level scheduler picks which container to run, and then a
> configurable per-container scheduler picks a task from that container.

What do you think about Plugsched? Peter Williams introduced a simple
scheduler interface for scheduler testing purposes. It should be
possible to integrate into your CPU Controller. The CPU Controller seems
to be quite suited for that purpose, as far as I can appraise after
reading some of your documentation.

Unfortunately, I didn't know about CKRM some months ago, when we decided
to use cpusets. As I wrote, Dynsched is a student project at sunset and
it's future is quite ambiguous. Maybe we'll find some time to take a
look at.

> But (having glanced at the code even less than you) it sounded like it
> was intended to be a single level scheduler, configured on a per-cpu
> basis. In that case tying it to (exclusive) cpusets sounds like it
> might be more reasonable.

You're right. We tie up the scheduler to cpus with some per_cpu
functionality, and chose cpusets for management, cause we didn't want
add another interface (e.g sysfs files for each cpu). Cpusets is quite
adequate for our purpose, but there are lots of issues we're currently
dealing with. Think about (not exclusive) subsets with different
schedulers...

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