PROBLEM: tickless scheduling
in [Kernel]
|
Prev: staging: hv: Optimize adj_guesttime function and add more detailed comments
Next: s3c-fb: added patch series for s5pv210 and some features.
From: Donald Allen on 17 May 2010 10:50 On Mon, May 17, 2010 at 10:29 AM, Arjan van de Ven <arjan(a)infradead.org> wrote: > On Mon, 17 May 2010 10:11:51 -0400 > Donald Allen <donaldcallen(a)gmail.com> wrote: > >> On Mon, May 17, 2010 at 10:04 AM, Arjan van de Ven >> <arjan(a)infradead.org> wrote: >> > On Mon, 17 May 2010 09:44:47 -0400 >> > Donald Allen <donaldcallen(a)gmail.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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Donald Allen on 17 May 2010 11:30 Stefan -- Would you check the BIOS on your machine and report the maker and version number? If you've followed this, I'm especially interested to know if it's a Phoenix BIOS. Thanks -- /Don On Sun, May 16, 2010 at 12:14 PM, Stefan Biereigel <security(a)biereigel-wb.de> wrote: > >> Attached. This is from the 2.6.30 kernel on the Arch Linux install cd. >> >> Here's another bit of data. As I've said previously, the problems I'm >> reporting were observed on a Toshiba NB310-305 netbook with a >> single-core Atom 450 processor. I just built myself a mini-ITX system >> using the Intel D510MO motherboard, which provides a dual-core D510 >> Atom processor. The other hardware on the board is similar to the >> Toshiba. I installed the same Slackware snapshot I used on the >> Toshiba, and did the home directory transfer without any problem at >> all with the default tickless kernel. The hardware isn't identical, >> and while I don't know the internals of the Linux kernel at all, my >> gut, backed up by many years of OS development work in scheduling and >> memory management, is telling me that the key difference is dual- vs. >> single-core. Just a guess. >> >> Hope this helps -- >> >> /Don >> > > Hello everyone, > > I hope I can add something here, because I am experiencing the exact same > Problem as Don describes. I'm running a PackardBell EasyNote MB89 featuring > a Core 2 Duo, 4 GB of RAM, Intel Chipset (Santa Rosa), SATA HDD. My Machine > even hangs at boot, absolutely doing nothing until i wiggle the touchpad. > This is definately reproduceable, but I think it doesn't occur that often in > X-Window-System, if X is off I can just wait a couple of seconds and there I > go. > > I compiled other kernels myself with tickless disabled and Ticks set to > various values (250, 1000) which completely resolved my problem. If you > want, I can get you some Output/logs/whatever because I'm fixed to using > this kernel ATM (which doesn't really hurt because I use X and son't shut > down my Notebook that often). > Even though I don't know what exact kernel-version this problem brings > (using another machine ATM from vacation) I can say that I existed since > Opensuse 11.1 I guess, so maybe 2.6.30 and above. > > Hope I can help -- > > Stefan > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Biereigel on 17 May 2010 12:20
Am 17.05.2010 17:26, schrieb Donald Allen: > Stefan -- > > Would you check the BIOS on your machine and report the maker and > version number? If you've followed this, I'm especially interested to > know if it's a Phoenix BIOS. > > Thanks -- > /Don Hello Don, I did try some things here. pci=nomsi didn't work really, but I think it decreased the rate of stucks, even though I'm not sure. My BIOS is a Phoenix TrustedCore with version number PG2G3A08, should be from 7/2009 or so. I will try my next boot with hpet=disable and report my results. Thanks for your help! Stefan DK3SB -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |