linux-kernel - Re: [RFC] Imprecise timers.

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]

Message-ID: <20080811173526.GA28661@linux-os.sc.intel.com>
Date:	Mon, 11 Aug 2008 10:35:26 -0700
From:	Venki Pallipadi <venkatesh.pallipadi@...el.com>
To:	Pavel Machek <pavel@...e.cz>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	"arjan@...radead.org" <arjan@...radead.org>
Subject: Re: [RFC] Imprecise timers.

On Sat, Aug 09, 2008 at 05:54:47AM -0700, Pavel Machek wrote:
> On Mon 2008-07-28 17:36:57, Pallipadi, Venkatesh wrote:
> >
> >
> > >-----Original Message-----
> > >From: linux-kernel-owner@...r.kernel.org
> > >[mailto:linux-kernel-owner@...r.kernel.org] On Behalf Of David
> > >Woodhouse
> > >Sent: Monday, July 21, 2008 8:03 PM
> > >To: linux-kernel@...r.kernel.org
> > >Cc: Thomas Gleixner; Ingo Molnar; arjan@...radead.org
> > >Subject: [RFC] Imprecise timers.
> > >
> > >Many users of timers don't really care too much about exactly
> > >when their
> > >timer fires -- and waking a CPU to satisfy such a timer is a waste of
> > >power. This patch implements a 'range' timer which will fire
> > >at a 'convenient'
> > >moment within given constraints.
> > >
> > >It's implemented by a deferrable timer at the beginning of the range,
> > >which will run some time later when the CPU happens to be awake. And a
> > >non-deferrable timer at the hard deadline, to ensure it really does
> > >happen by then.
> > >
> >
> > One concern I have is drivers using range_timers thinking that they need
> > some upper bound, while all they need is a simple deferrable timer. With that
> > we will have multiple timers waking up the CPU all the time (say, on
> > different CPUs) problem again. Even without the timers waking up all
> 
> I don't get it. Who has timers that can be deferred forever? At that
> point they may simply not set the timer at all, right?
> 

I don't think I said drivers have or need timers that can be deferred forever.

My point is, is it worth the overhead of setting and deleting additional timer,
just because drivers think that they need to use this new interface,
need to set a upper bound and come up with random upper bounds.
Apart from the overhead of setup and teardown we will somewhat negate the
benefits of deferrable timers as the upper bound hard timers can fire at
different times waking up the CPUs frequently.

I understand that some drivers need this kind of upper limit. I am not sure
whether all drivers need it and if not, how can we restrict drivers from using
this when they don't really need it.

Thanks,
Venki


--
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/