linux-kernel - Re: [tip:core/futexes] futex: use current->time_slack

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]

Date:	Thu, 12 Mar 2009 22:43:40 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Darren Hart <dvhltc@...ibm.com>
cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>, mingo@...hat.com,
	hpa@...or.com, linux-kernel@...r.kernel.org, rusty@...tcorp.com.au,
	mingo@...e.hu, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:core/futexes] futex: use current->time_slack_ns for rt
 tasks too

On Thu, 12 Mar 2009, Darren Hart wrote:
> Arjan van de Ven wrote:
> > Peter Zijlstra wrote:
> > > Looking at the default_timer_slack_ns stuff, do we want something like
> > > the below?
> > 
> > the original idea was that you had a default slack that you got from exec
> > time,
> > and then something you could just tweak around yourself independently....
> > 
> > this would throw that out of the window.
> 
> It seems to me that changing your scheduling class from userspace would be
> reasonable justification to change the timer slack to a default value for that
> class.  Thoughts?

We have already five locations in the kernel where we do policy
decisions on the slack value for rt-tasks. Such things need to be
decided at fork time and modified by scheduler class changes or the
prctl interface and not at random places where we need to hand the
slack value to the hrtimer code.

We just want to use task->timer_slack_ns and be done.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/