From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751412AbcBFCyf (ORCPT <rfc822;w@1wt.eu>);
	Fri, 5 Feb 2016 21:54:35 -0500
Received: from mga11.intel.com ([192.55.52.93]:19462 "EHLO mga11.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750831AbcBFCye (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Fri, 5 Feb 2016 21:54:34 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.22,403,1449561600"; 
   d="scan'208";a="878240512"
Subject: Re: [PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack
 of an arbitrary thread.
To: John Stultz <john.stultz@linaro.org>
References: <1454695723-4393-1-git-send-email-john.stultz@linaro.org>
 <20160205121353.63d65c6b33a153bd9f863d8b@linux-foundation.org>
 <CALAqxLVd=E5JuGdPXs8AL8gO7o1VAm0A-V=ZYVz8pz+NWeRRHA@mail.gmail.com>
 <20160205123230.bd8bd228a0f3798a281266eb@linux-foundation.org>
 <CALAqxLXJ7fu0kpnG5PFLnmMB=wMeV+9nz1zf9yLATzT8MaDsjg@mail.gmail.com>
 <CAGXu5j+W0oOCu1RR9FpEwX8ztiNHnpGpO2PyS54oMG85Yf08GQ@mail.gmail.com>
 <20160205125008.15ccbdbe82afc3521a8ee381@linux-foundation.org>
 <CALAqxLUc0-TFOxV_-Co0t+Qmu8aE01rDkGfDTTepZfCCZMb70g@mail.gmail.com>
 <CALAqxLUtajtXW_33VCuDE6gkfYugSPAX8YyzjA5p9P9zcDX3sA@mail.gmail.com>
 <56B55753.6080606@linux.intel.com>
 <CALAqxLX6vNdowBEiJ2DtcUiCRrwSe7dDhCJQ=U7476xTKf20FA@mail.gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        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>
From: Arjan van de Ven <arjan@linux.intel.com>
Message-ID: <56B56069.5050904@linux.intel.com>
Date: Fri, 5 Feb 2016 18:54:33 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CALAqxLX6vNdowBEiJ2DtcUiCRrwSe7dDhCJQ=U7476xTKf20FA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>> 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.
>
> So I'd think it would be mostly theoretical, but in my testing on a
> VM, setting the timerslack for bash to 10 secs made time sleep 1 take
> ~10.5 seconds. So its apparently not too hard to coalesce fairly far
> out (I need to spend a bit more time to verify that events really
> weren't happening during that time and we're not just doing
> unnecessary delays with the extra slack).

99% sure you're hitting something else;
we look pretty much only 1 ahead in the queue for timers to run to see if
they can be run, once we hit a timer that's not ready yet we stop.
your 10 second ahead is behind a whole bunch of other not-ready ones
so won't even be looked at until its close


> But yea. My main concern is that if we do a consistent 64bit interface
> for all arches in the /proc/<pid>/timerslack_ns interface, it will
> make PR_GET_TIMERSLACK return incorrect results on 32bit systems when
> the slack is >= 2^32.

or we return UINT_MAX for that case. not too hard.