From: Arjan van de Ven <arjan@linux.intel.com>
To: John Stultz <john.stultz@linaro.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.org>,
lkml <linux-kernel@vger.kernel.org>,
Ruchi Kandoi <kandoiruchi@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Oren Laadan <orenl@cellrox.com>,
Rom Lemarchand <romlem@android.com>,
Android Kernel Team <kernel-team@android.com>
Subject: Re: [PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread.
Date: Fri, 5 Feb 2016 18:15:47 -0800 [thread overview]
Message-ID: <56B55753.6080606@linux.intel.com> (raw)
In-Reply-To: <CALAqxLUtajtXW_33VCuDE6gkfYugSPAX8YyzjA5p9P9zcDX3sA@mail.gmail.com>
On 2/5/2016 4:51 PM, John Stultz wrote:
> On Fri, Feb 5, 2016 at 2:35 PM, John Stultz <john.stultz@linaro.org> wrote:
>> On Fri, Feb 5, 2016 at 12:50 PM, Andrew Morton
>> <akpm@linux-foundation.org> wrote:
>>> On Fri, 5 Feb 2016 12:44:04 -0800 Kees Cook <keescook@chromium.org> wrote:
>>>> Could this be exposed as a writable /proc entry instead? Like the oom_* stuff?
>>>
>>> /proc/<pid>/timer_slack_ns, guarded by ptrace_may_access(), documented
>>> under Documentation/? Yup, that would work. It's there for all
>>> architectures from day one and there is precedent. It's not as nice,
>>> but /proc nasties will always be with us.
>>
>> Ok. I'll start working on that.
>
> Arjan/Thomas: One curious thing I noticed here while writing some
> documentation. The timer_slack_ns value in the task struct is a
> unsigned long.
>
> So this means PR_SET_TIMERSLACK limits the maximum slack on 32 bit
> machines to ~4 seconds. Where on 64bit machines it can be quite a bit
> longer (unreasonably long, really :).
originally when we created timerslack, 4 seconds was an eternity and good enough for everyone
by a mile... (assumption was practical upper limit being in the 15 msec range)
and most of the RT guys would only tolerate a little bit of it
is there any real/practial use of going longer than 4 seconds? if there
is then yeah fixing it makes sense.
if it's just theoretical... shrug... 32 bit systems have a bunch of
other limits/differences a well.
next prev parent reply other threads:[~2016-02-06 2:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 18:08 [PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread John Stultz
2016-02-05 20:10 ` Kees Cook
2016-02-05 20:18 ` John Stultz
2016-02-05 20:13 ` Andrew Morton
2016-02-05 20:23 ` John Stultz
2016-02-05 20:32 ` Andrew Morton
2016-02-05 20:39 ` John Stultz
2016-02-05 20:44 ` Kees Cook
2016-02-05 20:50 ` Andrew Morton
2016-02-05 22:35 ` John Stultz
2016-02-06 0:51 ` John Stultz
2016-02-06 1:56 ` Andrew Morton
2016-02-06 2:41 ` John Stultz
2016-02-06 2:15 ` Arjan van de Ven [this message]
2016-02-06 2:50 ` John Stultz
2016-02-06 2:54 ` Arjan van de Ven
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=56B55753.6080606@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=john.stultz@linaro.org \
--cc=kandoiruchi@google.com \
--cc=keescook@chromium.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=orenl@cellrox.com \
--cc=romlem@android.com \
--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.