mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Roger Larsson <roger.larsson@norran.net>
To: linux-audio-dev@music.columbia.edu
Cc: "Jack O'Quin" <joq@io.com>, linux-kernel@vger.kernel.org
Subject: [CODE RFC] redefining sched_setscheduler using LD_PRELOAD
Date: Fri, 14 Nov 2003 06:15:06 +0100	[thread overview]
Message-ID: <200311140615.06606.roger.larsson@norran.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

Hi,

(Jack O'Quin got me thinking about rt_monitor again - thanks!)

This is an alternative to capabilities / SCHED_SOFTRR...

I use my old rt_monitor 
* protects the system on RT overload
* performs the actual setting of scheduler type
* it does not even have to be visible for lusers!

My old testprogram RT has been converted to
a library fit for preloading.

It works like this.

As root start
# rt_monitor

As normal user start latencytest
$ ./rts path/to/latencytest none 2 128 10

rts has two options
	-i	do not raise the priority.
	-v	be more verbose.
* It does also limit the effective min/max range.

Do also try (don't try this as root unless rt_monitor is running)
$ ./rts path/to/latencytest none 2 1024 99
* In this case rt_monitor captures the process and renices it.
  (SCHED_OTHER + nice)

BUGS:
* better build and installation system
* could ignore RT processes already running when rt_monitor starts
* rt_monitor functionallity has not been reverified...
* it can't lock memory :-( No PIDs in calls.
* code that checks uid before using the redefined functions won't work
  (I have an modified latencytest)
* client get stuck if there is no monitor running.

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden





[-- Attachment #2: rts.zip --]
[-- Type: application/x-zip, Size: 15894 bytes --]

                 reply	other threads:[~2003-11-14  5:14 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=200311140615.06606.roger.larsson@norran.net \
    --to=roger.larsson@norran.net \
    --cc=joq@io.com \
    --cc=linux-audio-dev@music.columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®