Re: [ck] Re: [PATCH] mm: swap prefetch improvements
On Tue, 22 May 2007 20:37:54 +1000 Con Kolivas <[EMAIL PROTECTED]> wrote: > On Tuesday 22 May 2007 20:25, Ingo Molnar wrote: > > * Con Kolivas <[EMAIL PROTECTED]> wrote: > > > > > there was nothing else running on the system - so i suspect the > > > > > swapin activity flagged 'itself' as some 'other' activity and > > > > > stopped? The swapins happened in 4 bursts, separated by 5 seconds > > > > > total idleness. > > > > > > > > I've noted burst swapins separated by some seconds of pause in my > > > > desktop system too (with sp_tester and an idle gnome). > > > > > > That really is expected, as just about anything, including journal > > > writeout, would be enough to put it back to sleep for 5 more seconds. > > > > note that nothing like that happened on my system - in the > > swap-prefetch-off case there was _zero_ IO activity during the sleep > > period. > > Ok, granted it's _very_ conservative. I really don't want to risk its > presence > being a burden on anything, and the iowait it induces probably makes it turn > itself off for another PREFETCH_DELAY (5s). I really don't want to cross the > line to where it is detrimental in any way. Not dropping out on a > cond_resched and perhaps making the delay tunable should be enough to make it > a little less "sleepy". > > -- > -ck Hi. I just did some video encoding on my desktop and I was noticing (for the first time in a while) that running apps had to hit swap quite a lot when I switched to them (the encoding was going at full blast for most of the day, and most of the time other running apps were idle). Now, a good half of my RAM appeared to be free during all this, so I was thinking at the time that it would be nice if swap prefetch could be tunably more aggressive. I guess it would be ideal in this case if it could kick in during tunably low disk-IO periods, even if the CPU is rather busy. I'm sure you've considered this, so I only butt in here to cast a vote for it. :) Of course, I could be completely wrong about the possibility.. and I seem to remember that the disk cache can take up about half the ram by default without this showing up in 'gnome-system-monitor'... which I guess might happen during heavy encoding.. but even if it did, I could have set the limit lower, and would then have still appreciated prefetching. Ash - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: swap prefetch improvements
On Wed, 23 May 2007 08:50:01 +1000 Con Kolivas <[EMAIL PROTECTED]> wrote: > On Wednesday 23 May 2007 06:42, Ash Milsted wrote: > > Hi. I just did some video encoding on my desktop and I was noticing > > (for the first time in a while) that running apps had to hit swap quite > > a lot when I switched to them (the encoding was going at full blast for > > most of the day, and most of the time other running apps were > > idle). Now, a good half of my RAM appeared to be free during all this, > > so I was thinking at the time that it would be nice if swap prefetch > > could be tunably more aggressive. I guess it would be ideal in this > > case if it could kick in during tunably low disk-IO periods, even if > > the CPU is rather busy. I'm sure you've considered this, so I only butt > > in here to cast a vote for it. :) > > In this case nicing the video encode should be enough to make it prefetch > even > during heavy cpu usage. It detects the total nice level rather than the cpu > usage. > Cunning, but I guess the regular (less than 5 seconds apart) reads/writes during the encoding process would cause prefetching to hold off, no? I had used nice and ionice to reduce the encoder priority, which made desktop apps pretty responsive, except when they had to hit swap. If swap prefetch is using the idle io-priority I suppose it would hardly affect performance if it kicked in during such use, since it would operate in between the encoder reads anyway (assuming the encoder is at higher ioprio), right ? > > I plan to make it prefetch more aggressively by default soon and make it more > tunable too. > 'Sounds good! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc2 regression vs. 2.6.20: AT keyboard only works with pci=noacpi
On Wed, 7 Mar 2007 23:49:14 + Ash Milsted <[EMAIL PROTECTED]> wrote: > On Wed, 7 Mar 2007 21:25:34 +0000 > Ash Milsted <[EMAIL PROTECTED]> wrote: > > > On Wed, 7 Mar 2007 12:00:04 + > > Ash Milsted <[EMAIL PROTECTED]> wrote: > > > > > On Sun, 4 Mar 2007 14:23:50 + > > > Ash Milsted <[EMAIL PROTECTED]> wrote: > > > > > > > On Sat, 3 Mar 2007 15:14:24 + > > > > Ash Milsted <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi, > > > > > With 2.6.21-rc2-git1 I have a problem with my ps/2 port keyboard - it > > > > > only works > > > > > with one of the following on the command-line: > > > > > - nolapic > > > > > - irqfixup > > > > > - pci=noacpi > > > > > Otherwise it gets stuck with the numlock on. > > > > > The following options have no effect: > > > > > - nohz=off (who knows eh?) > > > > > - pci=nomsi > > > > > > > > snip > > > > > > > > > > Ash > > > > > > > > Just checked 2.6.21-rc2-mm1, still has the problem. > > > > Also, acpi=noirq fixes it too. > > > > To clarify, the problem is that my ps/2 port keyboard is completely > > > > frozen > > > > on boot - usually it gets activated when udev probes for hardware (my > > > > kernel > > > > config is highly modular). It worked fine with 2.6.20 and earlier with > > > > acpi > > > > taking care of interrupt routing. > > > > > > > > Ash > > > > > > Any thoughts on this? It still occurs with 2.6.21-rc3. Here's my config > > > in case that helps. You'll see that I have swap-prefetch patched in (I > > > also have RDSL and some VM changes in there), but I have confirmed that > > > the problem occurs with no extra patches. By the way, I tested mm1 with > > > a rather different config (I used my distro package) and still saw the > > > problem. > > > > > > Also, you should probably ignore that bit above where I suggest the > > > keyboard driver is being loaded as a module, because of course it > > > isn't.. Yet it does start responding (with pci=noacpi) at about that > > > time that udev does its thing. > > > > > schnip > > > > So, I tracked this down to 2.6.21-git7, the first snapshot that gives me > > this problem. Tellingly it does contain an input tree merge. I would git > > bisect > > but I don't have a local copy of the tree - I tried to get one, but it > > stopped > > halfway through the clone, probably because I had to use http... So, I hope > > that > > helps. > > > > Ash > > > > PS: I should have said I'm not subscribed, so please CC me on reply. > > PPS: That almost rhymes. Almost. > > Apologies for only replying to my own mails, but I need to be CC'd if > any alternative is to be convenient :) > > Linus, thanks for your detailed messages. I will try to get a bisect done, > but > the university firewall is likely to put up a fight against rsync as much as > it > does with the git protocol. We will see. And yeah, that 2.6.21-git7 business > was > a typo, should've been 2.6.20-git7, natch. > ker-cut >Argh, I can't believe I forgot to get this into my tree. Could you >please tell me if the patch below fixes ytour issue? Yup, that patch really hit the spot. Now I don't have to bisect :) Thanks for your help (both of you), Ash - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/6] 2.6.21-rc2: known regressions
On Wed, 07 Mar 2007 06:09:06 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Adrian Bunk wrote: > > Subject: AT keyboard only works with pci=noacpi > > References : http://lkml.org/lkml/2007/3/3/68 > > Submitter : Ash Milsted <[EMAIL PROTECTED]> > > Status : unknown > > > sounds like a BIOS bug, even though it appears to be a regression? > Resolved here: http://marc.theaimsgroup.com/?l=linux-kernel&m=117332735404395&w=2 Was a bug in the i8042 driver it seems. Ash - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] RSDL v0.30 cpu scheduler for mainline kernels
On Mon, 12 Mar 2007 10:58:11 +1100 Con Kolivas <[EMAIL PROTECTED]> wrote: > There are updated patches for 2.6.20, 2.6.20.2, 2.6.21-rc3 and 2.6.21-rc3-mm2 > to bring RSDL up to version 0.30 for download here: > > Full patches: > > http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched-rsdl-0.30.patch > http://ck.kolivas.org/patches/staircase-deadline/2.6.20.2-rsdl-0.30.patch > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-sched-rsdl-0.30.patch > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2-rsdl-0.30.patch > > incrementals: > > http://ck.kolivas.org/patches/staircase-deadline/2.6.20/2.6.20.2-rsdl-0.29-0.30.patch > http://ck.kolivas.org/patches/staircase-deadline/2.6.20.2/2.6.20.2-rsdl-0.29-0.30.patch > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3/2.6.21-rc3-rsdl-0.29-0.30.patch > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc3-mm2/2.6.21-rc3-mm2-rsdl-0.29-0.30.patch > > -- > -ck > ___ > http://ck.kolivas.org/faqs/replying-to-mailing-list.txt > ck mailing list - mailto: [EMAIL PROTECTED] > http://vds.kolivas.org/mailman/listinfo/ck Here's my experience with RSDL 0.30 on 2.6.21-rc3-git6 under my normal usage scenarios... Plain desktop use (web browsing, music, etc): no noticeable change Desktop use during kernel compile (no -j): The compile impacts desktop use more with RSDL, but this is easily solved by nice-ing the compile (default nice of 10 seems enough). The kind of impact I am talking about is e.g. occasional delays in scrolling in the browser etc. Desktop use whilst talking on Wengophone (run at nice -5): Under RSDL some GUI use e.g. opening a new folder in nautilus causes pops (buffer underruns) which do not occur with mainline. I suppose the changes in RSDL might require a lower nice value for equivalent performance, but (as a user) I am limited to -5. Low-latency audio with JACK and Ardour2: Rock-solid performance with either scheduler.. realtime works nicely. Playing Quake3 (proprietary nvidia driver): Plays smoothly for both schedulers. So, I suppose I'd like to know what to do about the Wengophone issue, because that really is a problem for me. I guess your re-worked -ive nice values might help? Ash - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] RSDL v0.30 cpu scheduler for mainline kernels
On Tue, 13 Mar 2007 11:45:50 -0600 "Chris Friesen" <[EMAIL PROTECTED]> wrote: > Lee Revell wrote: > > > Sounds like Wengophone is broken. It should be using RT threads for > > time critical work, as JACK and Ardour2 are doing. > > If the app has root privileges to set RT policy, then it could also set > deeply negative nice values as well. > > Doesn't reallly help the regular user with no privileges. > > Chris Well my distro (Arch) does have the relevant PAM support for giving users realtime capabilities, but naturally Wengophone is not designed to make use of them (does any internet phone do this?). The main problem is that it worked fine on mainline and does not with RSDL, and even boosting it to nice -19 (with root privs) makes no difference (although I only tested nice -19 with the slightly dodgy patch Con posted for Mike Galbraith, that patch reportedly only affects a few positive nice values). Two possibilities occur to me: 1. RSDL just isn't giving sched_other tasks as low latency as mainline (Wengophone is not using much CPU time from as far as top can tell). 2. The problem is actually caused by increased network latency somehow caused by RSDL (this is an internet phone). I would like to add that the problem seems to be latency *spikes* that occur when there is sudden activity in another app (say, I open a folder in nautilus) that was previously largely idle. I suppose if Con does what he says and reduces latency overall, this problem might disappear. For now, of course, I hope his neck gets better :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc2 regression vs. 2.6.20: AT keyboard only works with pci=noacpi
On Sun, 4 Mar 2007 14:23:50 + Ash Milsted <[EMAIL PROTECTED]> wrote: > On Sat, 3 Mar 2007 15:14:24 +0000 > Ash Milsted <[EMAIL PROTECTED]> wrote: > > > Hi, > > With 2.6.21-rc2-git1 I have a problem with my ps/2 port keyboard - it only > > works > > with one of the following on the command-line: > > - nolapic > > - irqfixup > > - pci=noacpi > > Otherwise it gets stuck with the numlock on. > > The following options have no effect: > > - nohz=off (who knows eh?) > > - pci=nomsi > > snip > > > > Ash > > Just checked 2.6.21-rc2-mm1, still has the problem. > Also, acpi=noirq fixes it too. > To clarify, the problem is that my ps/2 port keyboard is completely frozen > on boot - usually it gets activated when udev probes for hardware (my kernel > config is highly modular). It worked fine with 2.6.20 and earlier with acpi > taking care of interrupt routing. > > Ash Any thoughts on this? It still occurs with 2.6.21-rc3. Here's my config in case that helps. You'll see that I have swap-prefetch patched in (I also have RDSL and some VM changes in there), but I have confirmed that the problem occurs with no extra patches. By the way, I tested mm1 with a rather different config (I used my distro package) and still saw the problem. Also, you should probably ignore that bit above where I suggest the keyboard driver is being loaded as a module, because of course it isn't.. Yet it does start responding (with pci=noacpi) at about that time that udev does its thing. Anyhoo: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-beyond # Tue Mar 6 15:07:17 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="ash" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONF
Re: 2.6.21-rc2 regression vs. 2.6.20: AT keyboard only works with pci=noacpi
On Wed, 7 Mar 2007 12:00:04 + Ash Milsted <[EMAIL PROTECTED]> wrote: > On Sun, 4 Mar 2007 14:23:50 +0000 > Ash Milsted <[EMAIL PROTECTED]> wrote: > > > On Sat, 3 Mar 2007 15:14:24 + > > Ash Milsted <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > With 2.6.21-rc2-git1 I have a problem with my ps/2 port keyboard - it > > > only works > > > with one of the following on the command-line: > > > - nolapic > > > - irqfixup > > > - pci=noacpi > > > Otherwise it gets stuck with the numlock on. > > > The following options have no effect: > > > - nohz=off (who knows eh?) > > > - pci=nomsi > > > > snip > > > > > > Ash > > > > Just checked 2.6.21-rc2-mm1, still has the problem. > > Also, acpi=noirq fixes it too. > > To clarify, the problem is that my ps/2 port keyboard is completely frozen > > on boot - usually it gets activated when udev probes for hardware (my kernel > > config is highly modular). It worked fine with 2.6.20 and earlier with acpi > > taking care of interrupt routing. > > > > Ash > > Any thoughts on this? It still occurs with 2.6.21-rc3. Here's my config > in case that helps. You'll see that I have swap-prefetch patched in (I > also have RDSL and some VM changes in there), but I have confirmed that > the problem occurs with no extra patches. By the way, I tested mm1 with > a rather different config (I used my distro package) and still saw the > problem. > > Also, you should probably ignore that bit above where I suggest the > keyboard driver is being loaded as a module, because of course it > isn't.. Yet it does start responding (with pci=noacpi) at about that > time that udev does its thing. > schnip So, I tracked this down to 2.6.21-git7, the first snapshot that gives me this problem. Tellingly it does contain an input tree merge. I would git bisect but I don't have a local copy of the tree - I tried to get one, but it stopped halfway through the clone, probably because I had to use http... So, I hope that helps. Ash PS: I should have said I'm not subscribed, so please CC me on reply. PPS: That almost rhymes. Almost. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
