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]

Message-ID: <AANLkTinnRmY_00AwxOcqKp1DUtdYf8A7DnjodQ5hiaWd@mail.gmail.com>
Date:	Mon, 17 May 2010 10:45:13 -0400
From:	Donald Allen <donaldcallen@...il.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	john stultz <johnstul@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: PROBLEM: tickless scheduling

On Mon, May 17, 2010 at 10:29 AM, Arjan van de Ven <arjan@...radead.org> wrote:
> 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.

Thanks for above explanation.

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

This machine did come with XP.

I've changed the lilo.config (this is Slackware -- no grub by
default!) to boot by default with pci=nomsi. Tried it once and the
system came up without getting stuck. I will rebuild the kernel with
tickless enabled, since that appears to be a red herring, and will
report results when I have them.

I will also report to Toshiba and the BIOS supplier (Phoenix --
SecureCore v1.40).

/Don

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