linux-kernel - Re: PROBLEM: tickless scheduling

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:	Mon, 17 May 2010 07:29:53 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Donald Allen <donaldcallen@...il.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	john stultz <johnstul@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: PROBLEM: tickless scheduling

On Mon, 17 May 2010 10:11:51 -0400
Donald Allen <donaldcallen@...il.com> wrote:

> On Mon, May 17, 2010 at 10:04 AM, Arjan van de Ven
> <arjan@...radead.org> wrote:
> > On Mon, 17 May 2010 09:44:47 -0400
> > Donald Allen <donaldcallen@...il.com> wrote:
> >
> >> I will do the experiment suggested by Arjan van de Ven and report
> >> the results of that separately.
> 
> Just for my own information, is this correct:
> 
> I assume that tickless scheduling, rather than relying on periodic
> clock interrupts to wake up the scheduler, relies on interrupt
> handlers to somehow signal the system that the scheduler needs to run
> because they've just processed an event that has changed the state of
> the system?

well.. it relies on the hardware to signal the kernel that there's work
pending for a specific device. 

technically this is true for both tickless and without tickless.
but without tickless there's so much activity in the system that it
never really goes quiet (and in fact, some different power management
decisions may be made because of that)

> 
> If so, then it looks like using the msi-style device-specific
> interrupts isn't working reliably on this hardware? Or somehow the

that looks like a correct assumption to me.

> kernel (or a driver) is failing to handle the interrupts properly with
> msi enabled on certain hardware? I mention the latter only because of
> the report yesterday from someone else seeing the same symptoms I am
> on completely different hardware.

BIOSes breaking MSI is not entirely uncommon. Windows XP does not use
MSI for various things Linux does use MSI for, and so machines that come
with XP by default may not have this feature very well tested
unfortunately.

> 
> /Don
> 
> >
> >
> > since you're losing interrupts.. another good option to try is
> > "irqpoll"
> >
> >
> > --
> > Arjan van de Ven        Intel Open Source Technology Centre
> > For development, discussion and tips for power savings,
> > visit http://www.lesswatts.org
> >


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/