linux-kernel - Re: report a bug about sched

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

Message-ID: <20090725230100.GC15260@shareable.org>
Date:	Sun, 26 Jul 2009 00:01:00 +0100
From:	Jamie Lokier <jamie@...reable.org>
To:	sen wang <wangsen.linux@...il.com>
Cc:	Raistlin <raistlin@...ux.it>,
	Peter Zijlstra <peterz@...radead.org>, mingo@...e.hu,
	akpm@...ux-foundation.org, kernel@...ivas.org, npiggin@...e.de,
	arjan@...radead.org, linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: report a bug about sched_rt

sen wang wrote:
> but, to the realtime system  like a decoder, I think we should meet the rt
> task as we can.

If the realtime task is something like a video decoder feeding a
display, and it is bandwidth-throttled only to ensure things like SSH
and filesystem I/O are still available, then I have to agree with Sen,
you would want any "spare" CPU to go the video decoder in that
application, not the idle task.

> the RT scheduler is mainly used for realtime system which should have the
> different policy from fair task.

The RT scheduler is used for lots of different systems which you
haven't considered.

For your application, probably the way RT-bandwidth works is not
useful.  It's better for some other applications.

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