linux-kernel - Re: [PATCH 4/5] media/ivtv: Reduce default FIFO priority

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]

Message-ID: <20190801123806.GA31398@hirez.programming.kicks-ass.net>
Date:   Thu, 1 Aug 2019 14:38:06 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Andy Walls <andy@...verblocksystems.net>
Cc:     mingo@...nel.org, linux-kernel@...r.kernel.org,
        Andy Walls <awalls@...metrocast.net>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 4/5] media/ivtv: Reduce default FIFO priority

On Thu, Aug 01, 2019 at 08:24:22AM -0400, Andy Walls wrote:
> Hi Peter:
> 
> On Thu, 2019-08-01 at 13:13 +0200, Peter Zijlstra wrote:
> > The ivtv driver creates a FIFO-99 thread by default, reduce this to
> > FIFO-1.
> > 
> > FIFO-99 is the very highest priority available to SCHED_FIFO and
> > it not a suitable default; it would indicate the ivtv work is the
> > most important work on the machine.
> 
> ivtv based boards are legacy, convential PCI boards.  At this point,
> these old boards are generally installed in boxes dedicated to video
> capture (e.g. MythTV setups) or boxes dedicated to capturing VBI
> information, like closed captioning, for business intelligence.
> 
> For boxes dedicated to video or VBI capture, the ivtv work may very
> well be close to the most important work on the machine, to avoid
> dropping video frames or VBI data.
> 
> 
> > FIFO-1 gets it above all OTHER tasks, which seems high enough lacking
> > better justification.
> 
> I agree that FIFO-99 is the wrong default level.
> 
> However, in my opinion, threads responsible for real time data
> acquisition should have higher priority than the other kernel driver
> threads normally running at FIFO-50.
> 
> How about FIFO-51 as the default?

If the consumer of the data are RT tasks as well (I hadn't expected that
from a TV capture device) then I'd propose to use FIFO-50 as default.

The thing is, the moment you're doing actual proper RT, the admin needs
to configure things anyway, which then very much includes setting the
priority of interrupt threads and the like.

(that is exacty why pretty much everything defaults to FIFO-50)