All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andy Walls <andy@silverblocksystems.net>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org,
	Andy Walls <awalls@md.metrocast.net>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	linux-media@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 4/5] media/ivtv: Reduce default FIFO priority
Date: Thu, 1 Aug 2019 14:38:06 +0200	[thread overview]
Message-ID: <20190801123806.GA31398@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <7970f0e30d1eb83e7067225d07b923863bf1ac50.camel@silverblocksystems.net>

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)

  reply	other threads:[~2019-08-01 12:38 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01 11:13 [PATCH 0/5] Fix FIFO-99 abuse Peter Zijlstra
2019-08-01 11:13 ` [PATCH 1/5] sched/pci: Reduce psimon FIFO priority Peter Zijlstra
2019-08-01 17:49   ` Johannes Weiner
2019-08-01 18:31     ` Suren Baghdasaryan
2019-08-01 21:03       ` Suren Baghdasaryan
2019-08-01 21:02     ` Peter Zijlstra
2019-08-01 11:13 ` [PATCH 2/5] rcu/tree: Fix SCHED_FIFO params Peter Zijlstra
2019-08-01 13:51   ` Paul E. McKenney
2019-08-01 14:43     ` Peter Zijlstra
2019-08-01 15:33       ` Paul E. McKenney
2019-08-01 11:13 ` [PATCH 3/5] crypto: Reduce default RT priority Peter Zijlstra
2019-08-09  6:19   ` Herbert Xu
2019-08-01 11:13 ` [PATCH 4/5] media/ivtv: Reduce default FIFO priority Peter Zijlstra
2019-08-01 12:24   ` Andy Walls
2019-08-01 12:38     ` Peter Zijlstra [this message]
2019-08-02  8:58       ` Peter Zijlstra
2019-08-07  9:26         ` Hans Verkuil
2019-08-01 11:13 ` [PATCH 5/5] spi: Reduce kthread priority Peter Zijlstra
2019-08-01 11:26   ` Mark Brown
2019-08-01 12:07     ` Peter Zijlstra
2019-08-01 11:27   ` Geert Uytterhoeven
2019-08-01 12:12     ` Peter Zijlstra
2019-08-01 12:16       ` Geert Uytterhoeven
2019-08-01 11:27   ` Enric Balletbo i Serra
2019-08-01 12:17     ` Peter Zijlstra
2019-08-01 12:35       ` Mark Brown
2019-08-01 15:44         ` Doug Anderson
2019-08-02 11:22   ` Applied "spi: Reduce kthread priority" to the spi tree Mark Brown
2019-08-02 11:22     ` Mark Brown
2019-08-01 13:17 ` [PATCH 0/5] Fix FIFO-99 abuse Qais Yousef
2019-08-02  9:32   ` Peter Zijlstra
2019-08-02  9:50     ` Thomas Gleixner
2019-08-02 10:26     ` Qais Yousef
2019-08-02 12:41       ` Peter Zijlstra
2019-08-02 14:08         ` Qais Yousef
2019-08-02 14:33           ` Peter Zijlstra
2019-08-02 15:21             ` Qais Yousef

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190801123806.GA31398@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=andy@silverblocksystems.net \
    --cc=awalls@md.metrocast.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.