linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* ppc32: Weird process scheduling behaviour with 2.6.24-rc
@ 2008-01-18 12:34 Michel Dänzer
  2008-01-22 14:56 ` Michel Dänzer
  0 siblings, 1 reply; 33+ messages in thread
From: Michel Dänzer @ 2008-01-18 12:34 UTC (permalink / raw)
  To: linuxppc-dev


This is on a PowerBook5,8.

In a nutshell, things seem more sluggish in general than with 2.6.23.
But in particular, processes running at nice levels >0 can get most of
the CPU cycles available, slowing down processes running at nice level
0.

I've seen this since .24-rc5 (the first .24-rc I tried), and it's still
there with -rc8. I'd be surprised if this kind of behaviour remained
unfixed for that long if it affected x86, so  I presume it's powerpc
specific.

I thought it might be related to NO_HZ, but disabling that didn't help.
Below is the .config diff between the kernel I'm running currently and
the last known good. Any suggestions for other config tweaks I should
try, or for more information I could provide to narrow down the problem?

If there are no immediate ideas, I guess I'll try and bisect it...


--- /boot/config-2.6.23-1-powerpc	2008-01-07 01:59:03.000000000 +0100
+++ /boot/config-2.6.24-rc8	2008-01-16 18:29:54.000000000 +0100
@@ -1,7 +1,7 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.23
-# Mon Jan  7 00:35:52 2008
+# Linux kernel version: 2.6.24-rc8
+# Wed Jan 16 18:29:54 2008
 #
 # CONFIG_PPC64 is not set
 
@@ -21,8 +21,13 @@ CONFIG_PPC_STD_MMU_32=y
 # CONFIG_PPC_MM_SLICES is not set
 # CONFIG_SMP is not set
 CONFIG_PPC32=y
+CONFIG_WORD_SIZE=32
 CONFIG_PPC_MERGE=y
 CONFIG_MMU=y
+CONFIG_GENERIC_CMOS_UPDATE=y
+CONFIG_GENERIC_TIME=y
+CONFIG_GENERIC_TIME_VSYSCALL=y
+CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_GENERIC_HARDIRQS=y
 CONFIG_IRQ_PER_CPU=y
 CONFIG_RWSEM_XCHGADD_ALGORITHM=y
@@ -61,12 +66,24 @@ CONFIG_SYSVIPC_SYSCTL=y
 CONFIG_POSIX_MQUEUE=y
 CONFIG_BSD_PROCESS_ACCT=y
 CONFIG_BSD_PROCESS_ACCT_V3=y
-# CONFIG_TASKSTATS is not set
+CONFIG_TASKSTATS=y
+CONFIG_TASK_DELAY_ACCT=y
+CONFIG_TASK_XACCT=y
+CONFIG_TASK_IO_ACCOUNTING=y
 # CONFIG_USER_NS is not set
+# CONFIG_PID_NS is not set
 CONFIG_AUDIT=y
-# CONFIG_AUDITSYSCALL is not set
+CONFIG_AUDITSYSCALL=y
+CONFIG_AUDIT_TREE=y
 # CONFIG_IKCONFIG is not set
 CONFIG_LOG_BUF_SHIFT=17
+CONFIG_CGROUPS=y
+# CONFIG_CGROUP_DEBUG is not set
+CONFIG_CGROUP_NS=y
+CONFIG_FAIR_GROUP_SCHED=y
+CONFIG_FAIR_USER_SCHED=y
+# CONFIG_FAIR_CGROUP_SCHED is not set
+CONFIG_CGROUP_CPUACCT=y
 CONFIG_SYSFS_DEPRECATED=y
 CONFIG_RELAY=y
 CONFIG_BLK_DEV_INITRD=y
@@ -92,6 +109,7 @@ CONFIG_VM_EVENT_COUNTERS=y
 CONFIG_SLAB=y
 # CONFIG_SLUB is not set
 # CONFIG_SLOB is not set
+CONFIG_SLABINFO=y
 CONFIG_RT_MUTEXES=y
 # CONFIG_TINY_SHMEM is not set
 CONFIG_BASE_SMALL=0
@@ -124,7 +142,6 @@ CONFIG_DEFAULT_IOSCHED="cfq"
 # Platform support
 #
 CONFIG_PPC_MULTIPLATFORM=y
-# CONFIG_EMBEDDED6xx is not set
 # CONFIG_PPC_82xx is not set
 # CONFIG_PPC_83xx is not set
 # CONFIG_PPC_86xx is not set
@@ -138,6 +155,7 @@ CONFIG_PPC_PMAC=y
 # CONFIG_PPC_CELL is not set
 # CONFIG_PPC_CELL_NATIVE is not set
 # CONFIG_PQ2ADS is not set
+# CONFIG_EMBEDDED6xx is not set
 CONFIG_PPC_NATIVE=y
 # CONFIG_UDBG_RTAS_CONSOLE is not set
 CONFIG_MPIC=y
@@ -158,6 +176,8 @@ CONFIG_CPU_FREQ_STAT=m
 CONFIG_CPU_FREQ_STAT_DETAILS=y
 CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
 # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
+# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
+# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
 CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
 CONFIG_CPU_FREQ_GOV_POWERSAVE=m
 CONFIG_CPU_FREQ_GOV_USERSPACE=m
@@ -178,14 +198,18 @@ CONFIG_TAU=y
 #
 # Kernel options
 #
-CONFIG_HIGHMEM=y
+# CONFIG_HIGHMEM is not set
+CONFIG_TICK_ONESHOT=y
+# CONFIG_NO_HZ is not set
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
 # CONFIG_HZ_100 is not set
-CONFIG_HZ_250=y
-# CONFIG_HZ_300 is not set
+# CONFIG_HZ_250 is not set
+CONFIG_HZ_300=y
 # CONFIG_HZ_1000 is not set
-CONFIG_HZ=250
-CONFIG_PREEMPT_NONE=y
-# CONFIG_PREEMPT_VOLUNTARY is not set
+CONFIG_HZ=300
+# CONFIG_PREEMPT_NONE is not set
+CONFIG_PREEMPT_VOLUNTARY=y
 # CONFIG_PREEMPT is not set
 CONFIG_BINFMT_ELF=y
 CONFIG_BINFMT_MISC=m
@@ -200,6 +224,7 @@ CONFIG_FLATMEM_MANUAL=y
 CONFIG_FLATMEM=y
 CONFIG_FLAT_NODE_MEM_MAP=y
 # CONFIG_SPARSEMEM_STATIC is not set
+# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
 CONFIG_SPLIT_PTLOCK_CPUS=4
 # CONFIG_RESOURCES_64BIT is not set
 CONFIG_ZONE_DMA_FLAG=1
@@ -234,10 +259,7 @@ CONFIG_PCI_SYSCALL=y
 # CONFIG_PCIEPORTBUS is not set
 CONFIG_ARCH_SUPPORTS_MSI=y
 # CONFIG_PCI_MSI is not set
-
-#
-# PCCARD (PCMCIA/CardBus) support
-#
+CONFIG_PCI_LEGACY=y
 CONFIG_PCCARD=m
 # CONFIG_PCMCIA_DEBUG is not set
 CONFIG_PCMCIA=m
@@ -262,15 +284,14 @@ CONFIG_PCCARD_NONSTATIC=m
 #
 # Advanced setup
 #
-# CONFIG_ADVANCED_OPTIONS is not set
-
-#
-# Default settings for advanced configuration options are used
-#
+CONFIG_ADVANCED_OPTIONS=y
 CONFIG_HIGHMEM_START=0xfe000000
-CONFIG_LOWMEM_SIZE=0x30000000
-CONFIG_KERNEL_START=0xc0000000
-CONFIG_TASK_SIZE=0x80000000
+CONFIG_LOWMEM_SIZE_BOOL=y
+CONFIG_LOWMEM_SIZE=0x40000000
+CONFIG_KERNEL_START_BOOL=y
+CONFIG_KERNEL_START=0xb0000000
+CONFIG_TASK_SIZE_BOOL=y
+CONFIG_TASK_SIZE=0xb0000000
 CONFIG_BOOT_LOAD=0x00800000
 
 #
@@ -316,6 +337,7 @@ CONFIG_INET_TUNNEL=m
 CONFIG_INET_XFRM_MODE_TRANSPORT=m
 CONFIG_INET_XFRM_MODE_TUNNEL=m
 CONFIG_INET_XFRM_MODE_BEET=m
+CONFIG_INET_LRO=m
 CONFIG_INET_DIAG=m
 CONFIG_INET_TCP_DIAG=m
 CONFIG_TCP_CONG_ADVANCED=y
@@ -454,6 +476,7 @@ CONFIG_NETFILTER_XT_MATCH_STATE=m
 CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
 CONFIG_NETFILTER_XT_MATCH_STRING=m
 CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
+CONFIG_NETFILTER_XT_MATCH_TIME=m
 CONFIG_NETFILTER_XT_MATCH_U32=m
 CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
 
@@ -605,12 +628,7 @@ CONFIG_ECONET=m
 CONFIG_ECONET_AUNUDP=y
 CONFIG_ECONET_NATIVE=y
 CONFIG_WAN_ROUTER=m
-
-#
-# QoS and/or fair queueing
-#
 CONFIG_NET_SCHED=y
-CONFIG_NET_SCH_FIFO=y
 
 #
 # Queueing/Scheduling
@@ -657,10 +675,12 @@ CONFIG_NET_ACT_GACT=m
 CONFIG_GACT_PROB=y
 CONFIG_NET_ACT_MIRRED=m
 CONFIG_NET_ACT_IPT=m
+CONFIG_NET_ACT_NAT=m
 CONFIG_NET_ACT_PEDIT=m
 CONFIG_NET_ACT_SIMP=m
 # CONFIG_NET_CLS_POLICE is not set
 CONFIG_NET_CLS_IND=y
+CONFIG_NET_SCH_FIFO=y
 
 #
 # Network testing
@@ -686,6 +706,7 @@ CONFIG_BAYCOM_SER_FDX=m
 CONFIG_BAYCOM_SER_HDX=m
 # CONFIG_BAYCOM_PAR is not set
 # CONFIG_BAYCOM_EPP is not set
+# CONFIG_YAM is not set
 CONFIG_IRDA=m
 
 #
@@ -716,7 +737,9 @@ CONFIG_IRTTY_SIR=m
 # Dongle support
 #
 # CONFIG_DONGLE is not set
-# CONFIG_KINGSUN_DONGLE is not set
+CONFIG_KINGSUN_DONGLE=m
+CONFIG_KSDAZZLE_DONGLE=m
+CONFIG_KS959_DONGLE=m
 
 #
 # Old SIR device drivers
@@ -756,9 +779,11 @@ CONFIG_BT_HIDP=m
 #
 CONFIG_BT_HCIUSB=m
 CONFIG_BT_HCIUSB_SCO=y
+CONFIG_BT_HCIBTSDIO=m
 CONFIG_BT_HCIUART=m
 CONFIG_BT_HCIUART_H4=y
 CONFIG_BT_HCIUART_BCSP=y
+CONFIG_BT_HCIUART_LL=y
 CONFIG_BT_HCIBCM203X=m
 CONFIG_BT_HCIBPA10X=m
 CONFIG_BT_HCIBFUSB=m
@@ -776,8 +801,10 @@ CONFIG_FIB_RULES=y
 # Wireless
 #
 CONFIG_CFG80211=m
+CONFIG_NL80211=y
 CONFIG_WIRELESS_EXT=y
 CONFIG_MAC80211=m
+CONFIG_MAC80211_RCSIMPLE=y
 CONFIG_MAC80211_LEDS=y
 # CONFIG_MAC80211_DEBUGFS is not set
 # CONFIG_MAC80211_DEBUG is not set
@@ -790,7 +817,9 @@ CONFIG_IEEE80211_SOFTMAC=m
 # CONFIG_IEEE80211_SOFTMAC_DEBUG is not set
 CONFIG_RFKILL=m
 CONFIG_RFKILL_INPUT=m
+CONFIG_RFKILL_LEDS=y
 CONFIG_NET_9P=m
+CONFIG_NET_9P_FD=m
 # CONFIG_NET_9P_DEBUG is not set
 
 #
@@ -800,6 +829,7 @@ CONFIG_NET_9P=m
 #
 # Generic Driver Options
 #
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_STANDALONE=y
 CONFIG_PREVENT_FIRMWARE_BUILD=y
 CONFIG_FW_LOADER=m
@@ -868,6 +898,11 @@ CONFIG_IDE_PROC_FS=y
 # IDE chipset support/bugfixes
 #
 # CONFIG_IDE_GENERIC is not set
+# CONFIG_BLK_DEV_PLATFORM is not set
+
+#
+# PCI IDE chipsets support
+#
 CONFIG_BLK_DEV_IDEPCI=y
 CONFIG_IDEPCI_SHARE_IRQ=y
 CONFIG_IDEPCI_PCIBUS_ORDER=y
@@ -875,8 +910,6 @@ CONFIG_IDEPCI_PCIBUS_ORDER=y
 CONFIG_BLK_DEV_GENERIC=m
 # CONFIG_BLK_DEV_OPTI621 is not set
 CONFIG_BLK_DEV_IDEDMA_PCI=y
-# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
-# CONFIG_IDEDMA_ONLYDISK is not set
 CONFIG_BLK_DEV_AEC62XX=m
 # CONFIG_BLK_DEV_ALI15X3 is not set
 # CONFIG_BLK_DEV_AMD74XX is not set
@@ -909,7 +942,7 @@ CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y
 CONFIG_BLK_DEV_IDEDMA_PMAC=y
 # CONFIG_IDE_ARM is not set
 CONFIG_BLK_DEV_IDEDMA=y
-# CONFIG_IDEDMA_IVB is not set
+CONFIG_IDE_ARCH_OBSOLETE_INIT=y
 # CONFIG_BLK_DEV_HD is not set
 
 #
@@ -947,11 +980,14 @@ CONFIG_SCSI_WAIT_SCAN=m
 #
 CONFIG_SCSI_SPI_ATTRS=m
 CONFIG_SCSI_FC_ATTRS=m
+CONFIG_SCSI_FC_TGT_ATTRS=y
 CONFIG_SCSI_ISCSI_ATTRS=m
 CONFIG_SCSI_SAS_ATTRS=m
 CONFIG_SCSI_SAS_LIBSAS=m
 CONFIG_SCSI_SAS_ATA=y
 # CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
+CONFIG_SCSI_SRP_ATTRS=m
+CONFIG_SCSI_SRP_TGT_ATTRS=y
 CONFIG_SCSI_LOWLEVEL=y
 CONFIG_ISCSI_TCP=m
 CONFIG_BLK_DEV_3W_XXXX_RAID=m
@@ -974,6 +1010,7 @@ CONFIG_AIC79XX_REG_PRETTY_PRINT=y
 CONFIG_SCSI_AIC94XX=m
 # CONFIG_AIC94XX_DEBUG is not set
 CONFIG_SCSI_DPT_I2O=m
+CONFIG_SCSI_ADVANSYS=m
 CONFIG_SCSI_ARCMSR=m
 CONFIG_MEGARAID_NEWGEN=y
 CONFIG_MEGARAID_MM=m
@@ -1043,7 +1080,7 @@ CONFIG_SATA_VITESSE=m
 CONFIG_SATA_INIC162X=m
 # CONFIG_PATA_ALI is not set
 # CONFIG_PATA_AMD is not set
-# CONFIG_PATA_ARTOP is not set
+CONFIG_PATA_ARTOP=m
 # CONFIG_PATA_ATIIXP is not set
 # CONFIG_PATA_CMD640_PCI is not set
 # CONFIG_PATA_CMD64X is not set
@@ -1065,6 +1102,7 @@ CONFIG_PATA_MARVELL=m
 # CONFIG_PATA_OLDPIIX is not set
 # CONFIG_PATA_NETCELL is not set
 # CONFIG_PATA_NS87410 is not set
+# CONFIG_PATA_NS87415 is not set
 # CONFIG_PATA_OPTI is not set
 # CONFIG_PATA_OPTIDMA is not set
 # CONFIG_PATA_PCMCIA is not set
@@ -1097,11 +1135,9 @@ CONFIG_DM_ZERO=m
 CONFIG_DM_MULTIPATH=m
 CONFIG_DM_MULTIPATH_EMC=m
 CONFIG_DM_MULTIPATH_RDAC=m
+CONFIG_DM_MULTIPATH_HP=m
 CONFIG_DM_DELAY=m
-
-#
-# Fusion MPT device support
-#
+CONFIG_DM_UEVENT=y
 CONFIG_FUSION=y
 CONFIG_FUSION_SPI=m
 CONFIG_FUSION_FC=m
@@ -1153,6 +1189,7 @@ CONFIG_BONDING=m
 # CONFIG_MACVLAN is not set
 CONFIG_EQUALIZER=m
 CONFIG_TUN=m
+CONFIG_VETH=m
 CONFIG_ARCNET=m
 CONFIG_ARCNET_1201=m
 CONFIG_ARCNET_1051=m
@@ -1178,8 +1215,11 @@ CONFIG_SMSC_PHY=m
 CONFIG_BROADCOM_PHY=m
 CONFIG_ICPLUS_PHY=m
 CONFIG_FIXED_PHY=m
-# CONFIG_FIXED_MII_10_FDX is not set
-# CONFIG_FIXED_MII_100_FDX is not set
+CONFIG_FIXED_MII_10_FDX=y
+CONFIG_FIXED_MII_100_FDX=y
+CONFIG_FIXED_MII_1000_FDX=y
+CONFIG_FIXED_MII_AMNT=1
+CONFIG_MDIO_BITBANG=m
 CONFIG_NET_ETHERNET=y
 CONFIG_MII=y
 CONFIG_MACE=m
@@ -1205,6 +1245,10 @@ CONFIG_ULI526X=m
 CONFIG_PCMCIA_XIRCOM=m
 CONFIG_PCMCIA_XIRTULIP=m
 # CONFIG_HP100 is not set
+# CONFIG_IBM_NEW_EMAC_ZMII is not set
+# CONFIG_IBM_NEW_EMAC_RGMII is not set
+# CONFIG_IBM_NEW_EMAC_TAH is not set
+# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
 CONFIG_NET_PCI=y
 CONFIG_PCNET32=m
 CONFIG_PCNET32_NAPI=y
@@ -1212,6 +1256,9 @@ CONFIG_PCNET32_NAPI=y
 CONFIG_ADAPTEC_STARFIRE=m
 CONFIG_ADAPTEC_STARFIRE_NAPI=y
 CONFIG_B44=m
+CONFIG_B44_PCI_AUTOSELECT=y
+CONFIG_B44_PCICORE_AUTOSELECT=y
+CONFIG_B44_PCI=y
 # CONFIG_FORCEDETH is not set
 CONFIG_EEPRO100=m
 CONFIG_E100=m
@@ -1235,11 +1282,13 @@ CONFIG_VIA_RHINE_NAPI=y
 CONFIG_SC92031=m
 # CONFIG_NET_POCKET is not set
 CONFIG_NETDEV_1000=y
+# CONFIG_ACENIC is not set
 CONFIG_DL2K=m
 CONFIG_E1000=m
 CONFIG_E1000_NAPI=y
 # CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
 CONFIG_E1000E=m
+CONFIG_IP1000=m
 CONFIG_NS83820=m
 CONFIG_HAMACHI=m
 CONFIG_YELLOWFIN=m
@@ -1248,11 +1297,13 @@ CONFIG_R8169_NAPI=y
 CONFIG_R8169_VLAN=y
 CONFIG_SIS190=m
 CONFIG_SKGE=m
+# CONFIG_SKGE_DEBUG is not set
 CONFIG_SKY2=m
 # CONFIG_SKY2_DEBUG is not set
 # CONFIG_SK98LIN is not set
 CONFIG_VIA_VELOCITY=m
 CONFIG_TIGON3=m
+# CONFIG_BNX2 is not set
 CONFIG_MV643XX_ETH=m
 CONFIG_QLA3XXX=m
 CONFIG_ATL1=m
@@ -1261,17 +1312,21 @@ CONFIG_CHELSIO_T1=m
 CONFIG_CHELSIO_T1_1G=y
 CONFIG_CHELSIO_T1_NAPI=y
 CONFIG_CHELSIO_T3=m
+CONFIG_IXGBE=m
 CONFIG_IXGB=m
 CONFIG_IXGB_NAPI=y
 CONFIG_S2IO=m
 CONFIG_S2IO_NAPI=y
 CONFIG_MYRI10GE=m
 CONFIG_NETXEN_NIC=m
+CONFIG_NIU=m
 CONFIG_MLX4_CORE=m
 CONFIG_MLX4_DEBUG=y
+CONFIG_TEHUTI=m
 CONFIG_TR=y
 CONFIG_IBMOL=m
 CONFIG_IBMLS=m
+# CONFIG_3C359 is not set
 CONFIG_TMS380TR=m
 CONFIG_TMSPCI=m
 CONFIG_ABYSS=m
@@ -1294,6 +1349,8 @@ CONFIG_IPW2200_QOS=y
 # CONFIG_IPW2200_DEBUG is not set
 CONFIG_LIBERTAS=m
 CONFIG_LIBERTAS_USB=m
+CONFIG_LIBERTAS_CS=m
+CONFIG_LIBERTAS_SDIO=m
 # CONFIG_LIBERTAS_DEBUG is not set
 CONFIG_AIRO=m
 CONFIG_HERMES=m
@@ -1302,16 +1359,20 @@ CONFIG_PLX_HERMES=m
 CONFIG_TMD_HERMES=m
 CONFIG_NORTEL_HERMES=m
 CONFIG_PCI_HERMES=m
-CONFIG_ATMEL=m
-# CONFIG_PCI_ATMEL is not set
 CONFIG_PCMCIA_HERMES=m
 CONFIG_PCMCIA_SPECTRUM=m
-CONFIG_AIRO_CS=m
+CONFIG_ATMEL=m
+# CONFIG_PCI_ATMEL is not set
 CONFIG_PCMCIA_ATMEL=m
+CONFIG_AIRO_CS=m
 CONFIG_PCMCIA_WL3501=m
 CONFIG_PRISM54=m
 CONFIG_USB_ZD1201=m
 CONFIG_RTL8187=m
+CONFIG_ADM8211=m
+CONFIG_P54_COMMON=m
+CONFIG_P54_USB=m
+CONFIG_P54_PCI=m
 CONFIG_IWLWIFI=y
 # CONFIG_IWLWIFI_DEBUG is not set
 CONFIG_IWLWIFI_SENSITIVITY=y
@@ -1325,15 +1386,45 @@ CONFIG_HOSTAP_FIRMWARE=y
 CONFIG_HOSTAP_PLX=m
 CONFIG_HOSTAP_PCI=m
 CONFIG_HOSTAP_CS=m
-CONFIG_BCM43XX=m
-CONFIG_BCM43XX_DEBUG=y
-CONFIG_BCM43XX_DMA=y
-CONFIG_BCM43XX_PIO=y
-CONFIG_BCM43XX_DMA_AND_PIO_MODE=y
-# CONFIG_BCM43XX_DMA_MODE is not set
-# CONFIG_BCM43XX_PIO_MODE is not set
+# CONFIG_BCM43XX is not set
+CONFIG_B43=m
+CONFIG_B43_PCI_AUTOSELECT=y
+CONFIG_B43_PCICORE_AUTOSELECT=y
+CONFIG_B43_PCMCIA=y
+CONFIG_B43_LEDS=y
+CONFIG_B43_RFKILL=y
+# CONFIG_B43_DEBUG is not set
+CONFIG_B43_DMA=y
+CONFIG_B43_PIO=y
+CONFIG_B43_DMA_AND_PIO_MODE=y
+# CONFIG_B43_DMA_MODE is not set
+# CONFIG_B43_PIO_MODE is not set
+CONFIG_B43LEGACY=m
+CONFIG_B43LEGACY_PCI_AUTOSELECT=y
+CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y
+CONFIG_B43LEGACY_DEBUG=y
+CONFIG_B43LEGACY_DMA=y
+CONFIG_B43LEGACY_PIO=y
+CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y
+# CONFIG_B43LEGACY_DMA_MODE is not set
+# CONFIG_B43LEGACY_PIO_MODE is not set
 CONFIG_ZD1211RW=m
 # CONFIG_ZD1211RW_DEBUG is not set
+CONFIG_RT2X00=m
+CONFIG_RT2X00_LIB=m
+CONFIG_RT2X00_LIB_PCI=m
+CONFIG_RT2X00_LIB_USB=m
+CONFIG_RT2X00_LIB_FIRMWARE=y
+CONFIG_RT2X00_LIB_RFKILL=y
+CONFIG_RT2400PCI=m
+CONFIG_RT2400PCI_RFKILL=y
+CONFIG_RT2500PCI=m
+CONFIG_RT2500PCI_RFKILL=y
+CONFIG_RT61PCI=m
+CONFIG_RT61PCI_RFKILL=y
+CONFIG_RT2500USB=m
+CONFIG_RT73USB=m
+# CONFIG_RT2X00_DEBUG is not set
 
 #
 # USB Network Adapters
@@ -1342,7 +1433,6 @@ CONFIG_USB_CATC=m
 CONFIG_USB_KAWETH=m
 CONFIG_USB_PEGASUS=m
 CONFIG_USB_RTL8150=m
-CONFIG_USB_USBNET_MII=m
 CONFIG_USB_USBNET=m
 CONFIG_USB_NET_AX8817X=m
 CONFIG_USB_NET_CDCETHER=m
@@ -1421,11 +1511,13 @@ CONFIG_ATM_IDT77252=m
 # CONFIG_ATM_IDT77252_DEBUG is not set
 # CONFIG_ATM_IDT77252_RCV_ALL is not set
 CONFIG_ATM_IDT77252_USE_SUNI=y
+# CONFIG_ATM_AMBASSADOR is not set
 CONFIG_ATM_HORIZON=m
 # CONFIG_ATM_HORIZON_DEBUG is not set
 CONFIG_ATM_IA=m
 # CONFIG_ATM_IA_DEBUG is not set
 CONFIG_ATM_FORE200E_MAYBE=m
+# CONFIG_ATM_FORE200E_PCA is not set
 CONFIG_ATM_HE=m
 # CONFIG_ATM_HE_USE_SUNI is not set
 CONFIG_FDDI=y
@@ -1454,6 +1546,7 @@ CONFIG_SLHC=m
 CONFIG_NET_FC=y
 CONFIG_SHAPER=m
 CONFIG_NETCONSOLE=m
+CONFIG_NETCONSOLE_DYNAMIC=y
 CONFIG_NETPOLL=y
 CONFIG_NETPOLL_TRAP=y
 CONFIG_NET_POLL_CONTROLLER=y
@@ -1492,7 +1585,7 @@ CONFIG_PHONE_IXJ_PCMCIA=m
 #
 CONFIG_INPUT=y
 CONFIG_INPUT_FF_MEMLESS=m
-# CONFIG_INPUT_POLLDEV is not set
+CONFIG_INPUT_POLLDEV=m
 
 #
 # Userland interfaces
@@ -1502,9 +1595,6 @@ CONFIG_INPUT_MOUSEDEV_PSAUX=y
 CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
 CONFIG_INPUT_JOYDEV=m
-CONFIG_INPUT_TSDEV=m
-CONFIG_INPUT_TSDEV_SCREEN_X=240
-CONFIG_INPUT_TSDEV_SCREEN_Y=320
 CONFIG_INPUT_EVDEV=m
 # CONFIG_INPUT_EVBUG is not set
 
@@ -1555,8 +1645,8 @@ CONFIG_JOYSTICK_TWIDJOY=m
 # CONFIG_JOYSTICK_TURBOGRAFX is not set
 CONFIG_JOYSTICK_JOYDUMP=m
 CONFIG_JOYSTICK_XPAD=m
-# CONFIG_JOYSTICK_XPAD_FF is not set
-# CONFIG_JOYSTICK_XPAD_LEDS is not set
+CONFIG_JOYSTICK_XPAD_FF=y
+CONFIG_JOYSTICK_XPAD_LEDS=y
 CONFIG_INPUT_TABLET=y
 CONFIG_TABLET_USB_ACECAD=m
 CONFIG_TABLET_USB_AIPTEK=m
@@ -1583,6 +1673,9 @@ CONFIG_TOUCHSCREEN_USB_ETURBO=y
 CONFIG_TOUCHSCREEN_USB_GUNZE=y
 CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y
 CONFIG_TOUCHSCREEN_USB_IRTOUCH=y
+CONFIG_TOUCHSCREEN_USB_IDEALTEK=y
+CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y
+CONFIG_TOUCHSCREEN_USB_GOTOP=y
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_PCSPKR=m
 CONFIG_INPUT_ATI_REMOTE=m
@@ -1624,7 +1717,7 @@ CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_PCI=y
 CONFIG_SERIAL_8250_CS=m
-CONFIG_SERIAL_8250_NR_UARTS=16
+CONFIG_SERIAL_8250_NR_UARTS=32
 CONFIG_SERIAL_8250_RUNTIME_UARTS=4
 # CONFIG_SERIAL_8250_EXTENDED is not set
 
@@ -1635,6 +1728,7 @@ CONFIG_SERIAL_8250_RUNTIME_UARTS=4
 CONFIG_SERIAL_CORE=y
 CONFIG_SERIAL_CORE_CONSOLE=y
 CONFIG_SERIAL_PMACZILOG=y
+# CONFIG_SERIAL_PMACZILOG_TTYS is not set
 CONFIG_SERIAL_PMACZILOG_CONSOLE=y
 CONFIG_SERIAL_JSM=m
 # CONFIG_SERIAL_OF_PLATFORM is not set
@@ -1644,7 +1738,6 @@ CONFIG_UNIX98_PTYS=y
 CONFIG_PRINTER=m
 # CONFIG_LP_CONSOLE is not set
 # CONFIG_PPDEV is not set
-# CONFIG_TIPAR is not set
 CONFIG_HVC_DRIVER=y
 CONFIG_HVC_RTAS=y
 CONFIG_IPMI_HANDLER=m
@@ -1653,42 +1746,12 @@ CONFIG_IPMI_DEVICE_INTERFACE=m
 CONFIG_IPMI_SI=m
 CONFIG_IPMI_WATCHDOG=m
 CONFIG_IPMI_POWEROFF=m
-CONFIG_WATCHDOG=y
-# CONFIG_WATCHDOG_NOWAYOUT is not set
-
-#
-# Watchdog Device Drivers
-#
-CONFIG_SOFT_WATCHDOG=m
-CONFIG_WATCHDOG_RTAS=m
-
-#
-# PCI-based Watchdog Cards
-#
-CONFIG_PCIPCWATCHDOG=m
-CONFIG_WDTPCI=m
-CONFIG_WDT_501_PCI=y
-
-#
-# USB-based Watchdog Cards
-#
-CONFIG_USBPCWATCHDOG=m
 CONFIG_HW_RANDOM=y
 CONFIG_NVRAM=y
 CONFIG_GEN_RTC=y
 CONFIG_GEN_RTC_X=y
 CONFIG_R3964=m
 CONFIG_APPLICOM=m
-CONFIG_AGP=m
-CONFIG_AGP_UNINORTH=m
-CONFIG_DRM=m
-CONFIG_DRM_TDFX=m
-CONFIG_DRM_R128=m
-CONFIG_DRM_RADEON=m
-CONFIG_DRM_MGA=m
-# CONFIG_DRM_SIS is not set
-CONFIG_DRM_VIA=m
-CONFIG_DRM_SAVAGE=m
 
 #
 # PCMCIA character devices
@@ -1804,8 +1867,6 @@ CONFIG_BATTERY_DS2760=m
 # CONFIG_BATTERY_PMU is not set
 CONFIG_HWMON=y
 CONFIG_HWMON_VID=m
-CONFIG_SENSORS_ABITUGURU=m
-CONFIG_SENSORS_ABITUGURU3=m
 CONFIG_SENSORS_AD7418=m
 CONFIG_SENSORS_ADM1021=m
 CONFIG_SENSORS_ADM1025=m
@@ -1813,18 +1874,19 @@ CONFIG_SENSORS_ADM1026=m
 CONFIG_SENSORS_ADM1029=m
 CONFIG_SENSORS_ADM1031=m
 CONFIG_SENSORS_ADM9240=m
+CONFIG_SENSORS_ADT7470=m
 CONFIG_SENSORS_AMS=m
 CONFIG_SENSORS_AMS_PMU=y
 CONFIG_SENSORS_AMS_I2C=y
-CONFIG_SENSORS_ASB100=m
 CONFIG_SENSORS_ATXP1=m
 CONFIG_SENSORS_DS1621=m
+CONFIG_SENSORS_I5K_AMB=m
 CONFIG_SENSORS_F71805F=m
+CONFIG_SENSORS_F71882FG=m
 CONFIG_SENSORS_F75375S=m
-CONFIG_SENSORS_FSCHER=m
-CONFIG_SENSORS_FSCPOS=m
 CONFIG_SENSORS_GL518SM=m
 CONFIG_SENSORS_GL520SM=m
+CONFIG_SENSORS_IBMPEX=m
 CONFIG_SENSORS_IT87=m
 CONFIG_SENSORS_LM63=m
 CONFIG_SENSORS_LM70=m
@@ -1859,6 +1921,39 @@ CONFIG_SENSORS_W83L785TS=m
 CONFIG_SENSORS_W83627HF=m
 CONFIG_SENSORS_W83627EHF=m
 # CONFIG_HWMON_DEBUG_CHIP is not set
+CONFIG_WATCHDOG=y
+# CONFIG_WATCHDOG_NOWAYOUT is not set
+
+#
+# Watchdog Device Drivers
+#
+CONFIG_SOFT_WATCHDOG=m
+CONFIG_WATCHDOG_RTAS=m
+
+#
+# PCI-based Watchdog Cards
+#
+CONFIG_PCIPCWATCHDOG=m
+CONFIG_WDTPCI=m
+CONFIG_WDT_501_PCI=y
+
+#
+# USB-based Watchdog Cards
+#
+CONFIG_USBPCWATCHDOG=m
+
+#
+# Sonics Silicon Backplane
+#
+CONFIG_SSB_POSSIBLE=y
+CONFIG_SSB=m
+CONFIG_SSB_PCIHOST_POSSIBLE=y
+CONFIG_SSB_PCIHOST=y
+CONFIG_SSB_PCMCIAHOST_POSSIBLE=y
+CONFIG_SSB_PCMCIAHOST=y
+# CONFIG_SSB_DEBUG is not set
+CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
+CONFIG_SSB_DRIVER_PCICORE=y
 
 #
 # Multifunction device drivers
@@ -1885,6 +1980,7 @@ CONFIG_VIDEO_MSP3400=m
 CONFIG_VIDEO_CS53L32A=m
 CONFIG_VIDEO_WM8775=m
 CONFIG_VIDEO_WM8739=m
+CONFIG_VIDEO_VP27SMPX=m
 CONFIG_VIDEO_BT819=m
 CONFIG_VIDEO_BT856=m
 CONFIG_VIDEO_KS0127=m
@@ -1917,7 +2013,6 @@ CONFIG_VIDEO_CPIA2=m
 CONFIG_VIDEO_SAA5246A=m
 CONFIG_VIDEO_SAA5249=m
 CONFIG_TUNER_3036=m
-CONFIG_TUNER_TEA5761=y
 CONFIG_VIDEO_STRADIS=m
 CONFIG_VIDEO_ZORAN_ZR36060=m
 CONFIG_VIDEO_ZORAN=m
@@ -1939,7 +2034,9 @@ CONFIG_VIDEO_CX88_ALSA=m
 CONFIG_VIDEO_CX88_BLACKBIRD=m
 CONFIG_VIDEO_CX88_DVB=m
 CONFIG_VIDEO_CX88_VP3054=m
+CONFIG_VIDEO_CX23885=m
 CONFIG_VIDEO_IVTV=m
+CONFIG_VIDEO_FB_IVTV=m
 CONFIG_VIDEO_CAFE_CCIC=m
 CONFIG_V4L_USB_DRIVERS=y
 CONFIG_VIDEO_PVRUSB2=m
@@ -2009,6 +2106,7 @@ CONFIG_DVB_USB_DTT200U=m
 CONFIG_DVB_USB_OPERA1=m
 CONFIG_DVB_USB_AF9005=m
 CONFIG_DVB_USB_AF9005_REMOTE=m
+# CONFIG_DVB_TTUSB_BUDGET is not set
 CONFIG_DVB_TTUSB_DEC=m
 CONFIG_DVB_CINERGYT2=m
 # CONFIG_DVB_CINERGYT2_TUNING is not set
@@ -2085,6 +2183,7 @@ CONFIG_DVB_OR51211=m
 CONFIG_DVB_OR51132=m
 CONFIG_DVB_BCM3510=m
 CONFIG_DVB_LGDT330X=m
+CONFIG_DVB_S5H1409=m
 
 #
 # Tuners/PLL support
@@ -2094,6 +2193,9 @@ CONFIG_DVB_TDA826X=m
 CONFIG_DVB_TDA827X=m
 CONFIG_DVB_TUNER_QT1010=m
 CONFIG_DVB_TUNER_MT2060=m
+CONFIG_DVB_TUNER_MT2266=m
+CONFIG_DVB_TUNER_MT2131=m
+CONFIG_DVB_TUNER_DIB0070=m
 
 #
 # Miscellaneous devices
@@ -2104,37 +2206,45 @@ CONFIG_DVB_TUA6100=m
 CONFIG_VIDEO_SAA7146=m
 CONFIG_VIDEO_SAA7146_VV=m
 CONFIG_VIDEO_TUNER=m
-CONFIG_VIDEO_BUF=m
-CONFIG_VIDEO_BUF_DVB=m
+# CONFIG_VIDEO_TUNER_CUSTOMIZE is not set
+CONFIG_TUNER_MT20XX=m
+CONFIG_TUNER_TDA8290=m
+CONFIG_TUNER_TEA5761=m
+CONFIG_TUNER_TEA5767=m
+CONFIG_TUNER_SIMPLE=m
+CONFIG_VIDEOBUF_GEN=m
+CONFIG_VIDEOBUF_DMA_SG=m
+CONFIG_VIDEOBUF_VMALLOC=m
+CONFIG_VIDEOBUF_DVB=m
 CONFIG_VIDEO_BTCX=m
 CONFIG_VIDEO_IR_I2C=m
 CONFIG_VIDEO_IR=m
 CONFIG_VIDEO_TVEEPROM=m
 CONFIG_DAB=y
+CONFIG_USB_DABUSB=m
 
 #
 # Graphics support
 #
-CONFIG_BACKLIGHT_LCD_SUPPORT=y
-# CONFIG_LCD_CLASS_DEVICE is not set
-CONFIG_BACKLIGHT_CLASS_DEVICE=y
-
-#
-# Display device support
-#
-CONFIG_DISPLAY_SUPPORT=m
-
-#
-# Display hardware drivers
-#
+CONFIG_AGP=m
+CONFIG_AGP_UNINORTH=m
+CONFIG_DRM=m
+CONFIG_DRM_TDFX=m
+CONFIG_DRM_R128=m
+CONFIG_DRM_RADEON=m
+CONFIG_DRM_MGA=m
+# CONFIG_DRM_SIS is not set
+CONFIG_DRM_VIA=m
+CONFIG_DRM_SAVAGE=m
 CONFIG_VGASTATE=y
-CONFIG_VIDEO_OUTPUT_CONTROL=m
+# CONFIG_VIDEO_OUTPUT_CONTROL is not set
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_DDC=y
 CONFIG_FB_CFB_FILLRECT=y
 CONFIG_FB_CFB_COPYAREA=y
 CONFIG_FB_CFB_IMAGEBLIT=y
+# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
 # CONFIG_FB_SYS_FILLRECT is not set
 # CONFIG_FB_SYS_COPYAREA is not set
 # CONFIG_FB_SYS_IMAGEBLIT is not set
@@ -2160,6 +2270,7 @@ CONFIG_FB_CT65550=y
 # CONFIG_FB_ASILIANT is not set
 CONFIG_FB_IMSTT=y
 # CONFIG_FB_VGA16 is not set
+# CONFIG_FB_UVESA is not set
 CONFIG_FB_S1D13XXX=m
 CONFIG_FB_NVIDIA=y
 CONFIG_FB_NVIDIA_I2C=y
@@ -2204,6 +2315,19 @@ CONFIG_FB_PM3=m
 CONFIG_FB_SM501=m
 CONFIG_FB_IBM_GXT4500=m
 # CONFIG_FB_VIRTUAL is not set
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+# CONFIG_LCD_CLASS_DEVICE is not set
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+# CONFIG_BACKLIGHT_CORGI is not set
+
+#
+# Display device support
+#
+CONFIG_DISPLAY_SUPPORT=m
+
+#
+# Display hardware drivers
+#
 
 #
 # Console display driver support
@@ -2283,6 +2407,7 @@ CONFIG_SND_BT87X=m
 CONFIG_SND_CA0106=m
 CONFIG_SND_CMIPCI=m
 CONFIG_SND_CS4281=m
+# CONFIG_SND_CS46XX is not set
 CONFIG_SND_CS5530=m
 CONFIG_SND_DARLA20=m
 CONFIG_SND_GINA20=m
@@ -2306,6 +2431,18 @@ CONFIG_SND_FM801=m
 CONFIG_SND_FM801_TEA575X_BOOL=y
 CONFIG_SND_FM801_TEA575X=m
 CONFIG_SND_HDA_INTEL=m
+# CONFIG_SND_HDA_HWDEP is not set
+CONFIG_SND_HDA_CODEC_REALTEK=y
+CONFIG_SND_HDA_CODEC_ANALOG=y
+CONFIG_SND_HDA_CODEC_SIGMATEL=y
+CONFIG_SND_HDA_CODEC_VIA=y
+CONFIG_SND_HDA_CODEC_ATIHDMI=y
+CONFIG_SND_HDA_CODEC_CONEXANT=y
+CONFIG_SND_HDA_CODEC_CMEDIA=y
+CONFIG_SND_HDA_CODEC_SI3054=y
+CONFIG_SND_HDA_GENERIC=y
+CONFIG_SND_HDA_POWER_SAVE=y
+CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
 CONFIG_SND_HDSP=m
 CONFIG_SND_HDSPM=m
 CONFIG_SND_ICE1712=m
@@ -2313,7 +2450,9 @@ CONFIG_SND_ICE1724=m
 # CONFIG_SND_INTEL8X0 is not set
 # CONFIG_SND_INTEL8X0M is not set
 CONFIG_SND_KORG1212=m
+CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL=y
 CONFIG_SND_MAESTRO3=m
+CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL=y
 CONFIG_SND_MIXART=m
 CONFIG_SND_NM256=m
 CONFIG_SND_PCXHR=m
@@ -2327,7 +2466,9 @@ CONFIG_SND_VIA82XX=m
 CONFIG_SND_VIA82XX_MODEM=m
 CONFIG_SND_VX222=m
 CONFIG_SND_YMFPCI=m
+CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL=y
 CONFIG_SND_AC97_POWER_SAVE=y
+CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0
 
 #
 # ALSA PowerMac devices
@@ -2351,6 +2492,10 @@ CONFIG_SND_AOA_SOUNDBUS=m
 CONFIG_SND_AOA_SOUNDBUS_I2S=m
 
 #
+# SPI devices
+#
+
+#
 # USB devices
 #
 CONFIG_SND_USB_AUDIO=m
@@ -2381,6 +2526,7 @@ CONFIG_AC97_BUS=m
 CONFIG_HID_SUPPORT=y
 CONFIG_HID=m
 # CONFIG_HID_DEBUG is not set
+CONFIG_HIDRAW=y
 
 #
 # USB Input Devices
@@ -2423,7 +2569,7 @@ CONFIG_USB_DYNAMIC_MINORS=y
 CONFIG_USB_EHCI_HCD=m
 CONFIG_USB_EHCI_SPLIT_ISO=y
 CONFIG_USB_EHCI_ROOT_HUB_TT=y
-# CONFIG_USB_EHCI_TT_NEWSCHED is not set
+CONFIG_USB_EHCI_TT_NEWSCHED=y
 CONFIG_USB_ISP116X_HCD=m
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_PPC_OF=y
@@ -2487,6 +2633,7 @@ CONFIG_USB_SERIAL_AIRCABLE=m
 CONFIG_USB_SERIAL_AIRPRIME=m
 CONFIG_USB_SERIAL_ARK3116=m
 CONFIG_USB_SERIAL_BELKIN=m
+CONFIG_USB_SERIAL_CH341=m
 # CONFIG_USB_SERIAL_WHITEHEAT is not set
 CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
 CONFIG_USB_SERIAL_CP2101=m
@@ -2502,6 +2649,7 @@ CONFIG_USB_SERIAL_IR=m
 CONFIG_USB_SERIAL_GARMIN=m
 CONFIG_USB_SERIAL_IPW=m
 CONFIG_USB_SERIAL_KEYSPAN_PDA=m
+# CONFIG_USB_SERIAL_KEYSPAN is not set
 CONFIG_USB_SERIAL_KLSI=m
 CONFIG_USB_SERIAL_KOBIL_SCT=m
 CONFIG_USB_SERIAL_MCT_U232=m
@@ -2525,6 +2673,8 @@ CONFIG_USB_EZUSB=y
 #
 # USB Miscellaneous drivers
 #
+# CONFIG_USB_EMI62 is not set
+# CONFIG_USB_EMI26 is not set
 CONFIG_USB_ADUTUX=m
 CONFIG_USB_AUERSWALD=m
 CONFIG_USB_RIO500=m
@@ -2562,8 +2712,10 @@ CONFIG_USB_XUSBATM=m
 #
 CONFIG_USB_GADGET=m
 # CONFIG_USB_GADGET_DEBUG_FILES is not set
+# CONFIG_USB_GADGET_DEBUG_FS is not set
 CONFIG_USB_GADGET_SELECTED=y
 # CONFIG_USB_GADGET_AMD5536UDC is not set
+# CONFIG_USB_GADGET_ATMEL_USBA is not set
 # CONFIG_USB_GADGET_FSL_USB2 is not set
 CONFIG_USB_GADGET_NET2280=y
 CONFIG_USB_NET2280=m
@@ -2593,13 +2745,16 @@ CONFIG_MMC=m
 #
 CONFIG_MMC_BLOCK=m
 CONFIG_MMC_BLOCK_BOUNCE=y
+CONFIG_SDIO_UART=m
 
 #
 # MMC/SD Host Controller Drivers
 #
 CONFIG_MMC_SDHCI=m
+CONFIG_MMC_RICOH_MMC=m
 CONFIG_MMC_WBSD=m
 CONFIG_MMC_TIFM_SD=m
+# CONFIG_MMC_SPI is not set
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 
@@ -2649,6 +2804,7 @@ CONFIG_RTC_INTF_DEV=y
 # I2C RTC drivers
 #
 CONFIG_RTC_DRV_DS1307=m
+CONFIG_RTC_DRV_DS1374=m
 CONFIG_RTC_DRV_DS1672=m
 CONFIG_RTC_DRV_MAX6900=m
 CONFIG_RTC_DRV_RS5C372=m
@@ -2679,21 +2835,6 @@ CONFIG_RTC_DRV_V3020=m
 #
 # on-CPU RTC drivers
 #
-
-#
-# DMA Engine support
-#
-CONFIG_DMA_ENGINE=y
-
-#
-# DMA Clients
-#
-CONFIG_NET_DMA=y
-
-#
-# DMA Devices
-#
-CONFIG_INTEL_IOATDMA=m
 # CONFIG_AUXDISPLAY is not set
 
 #
@@ -2745,11 +2886,14 @@ CONFIG_GFS2_FS_LOCKING_NOLOCK=m
 CONFIG_GFS2_FS_LOCKING_DLM=m
 CONFIG_OCFS2_FS=m
 CONFIG_OCFS2_DEBUG_MASKLOG=y
+# CONFIG_OCFS2_DEBUG_FS is not set
 CONFIG_MINIX_FS=m
 CONFIG_ROMFS_FS=m
 CONFIG_INOTIFY=y
 CONFIG_INOTIFY_USER=y
 CONFIG_QUOTA=y
+CONFIG_QUOTA_NETLINK_INTERFACE=y
+CONFIG_PRINT_QUOTA_WARNING=y
 CONFIG_QFMT_V1=m
 CONFIG_QFMT_V2=m
 CONFIG_QUOTACTL=y
@@ -2790,7 +2934,6 @@ CONFIG_SYSFS=y
 CONFIG_TMPFS=y
 CONFIG_TMPFS_POSIX_ACL=y
 # CONFIG_HUGETLB_PAGE is not set
-CONFIG_RAMFS=y
 CONFIG_CONFIGFS_FS=m
 
 #
@@ -2814,10 +2957,7 @@ CONFIG_SYSV_FS=m
 CONFIG_UFS_FS=m
 # CONFIG_UFS_FS_WRITE is not set
 # CONFIG_UFS_DEBUG is not set
-
-#
-# Network File Systems
-#
+CONFIG_NETWORK_FILESYSTEMS=y
 CONFIG_NFS_FS=m
 CONFIG_NFS_V3=y
 CONFIG_NFS_V3_ACL=y
@@ -2836,12 +2976,11 @@ CONFIG_NFS_ACL_SUPPORT=m
 CONFIG_NFS_COMMON=y
 CONFIG_SUNRPC=m
 CONFIG_SUNRPC_GSS=m
+CONFIG_SUNRPC_XPRT_RDMA=m
 CONFIG_SUNRPC_BIND34=y
 CONFIG_RPCSEC_GSS_KRB5=m
 CONFIG_RPCSEC_GSS_SPKM3=m
-CONFIG_SMB_FS=m
-CONFIG_SMB_NLS_DEFAULT=y
-CONFIG_SMB_NLS_REMOTE="iso8859-1"
+# CONFIG_SMB_FS is not set
 CONFIG_CIFS=m
 # CONFIG_CIFS_STATS is not set
 # CONFIG_CIFS_WEAK_PW_HASH is not set
@@ -2885,10 +3024,6 @@ CONFIG_MSDOS_PARTITION=y
 CONFIG_KARMA_PARTITION=y
 # CONFIG_EFI_PARTITION is not set
 # CONFIG_SYSV68_PARTITION is not set
-
-#
-# Native Language Support
-#
 CONFIG_NLS=y
 CONFIG_NLS_DEFAULT="iso8859-1"
 CONFIG_NLS_CODEPAGE_437=m
@@ -2929,10 +3064,6 @@ CONFIG_NLS_ISO8859_15=m
 CONFIG_NLS_KOI8_R=m
 CONFIG_NLS_KOI8_U=m
 CONFIG_NLS_UTF8=m
-
-#
-# Distributed Lock Manager
-#
 CONFIG_DLM=m
 CONFIG_DLM_DEBUG=y
 # CONFIG_UCC_SLOW is not set
@@ -2958,18 +3089,17 @@ CONFIG_PLIST=y
 CONFIG_HAS_IOMEM=y
 CONFIG_HAS_IOPORT=y
 CONFIG_HAS_DMA=y
-
-#
-# Instrumentation Support
-#
+CONFIG_INSTRUMENTATION=y
 CONFIG_PROFILING=y
 CONFIG_OPROFILE=m
 # CONFIG_KPROBES is not set
+# CONFIG_MARKERS is not set
 
 #
 # Kernel hacking
 #
 # CONFIG_PRINTK_TIME is not set
+CONFIG_ENABLE_WARN_DEPRECATED=y
 CONFIG_ENABLE_MUST_CHECK=y
 CONFIG_MAGIC_SYSRQ=y
 CONFIG_UNUSED_SYMBOLS=y
@@ -2977,6 +3107,8 @@ CONFIG_DEBUG_FS=y
 # CONFIG_HEADERS_CHECK is not set
 # CONFIG_DEBUG_KERNEL is not set
 CONFIG_DEBUG_BUGVERBOSE=y
+# CONFIG_SAMPLES is not set
+# CONFIG_VIRQ_DEBUG is not set
 CONFIG_BOOTX_TEXT=y
 # CONFIG_PPC_EARLY_DEBUG is not set
 
@@ -2989,6 +3121,7 @@ CONFIG_SECURITY=y
 CONFIG_SECURITY_NETWORK=y
 CONFIG_SECURITY_NETWORK_XFRM=y
 CONFIG_SECURITY_CAPABILITIES=y
+CONFIG_SECURITY_FILE_CAPABILITIES=y
 # CONFIG_SECURITY_ROOTPLUG is not set
 CONFIG_SECURITY_SELINUX=y
 CONFIG_SECURITY_SELINUX_BOOTPARAM=y
@@ -3005,6 +3138,7 @@ CONFIG_ASYNC_MEMCPY=m
 CONFIG_ASYNC_XOR=m
 CONFIG_CRYPTO=y
 CONFIG_CRYPTO_ALGAPI=y
+CONFIG_CRYPTO_AEAD=m
 CONFIG_CRYPTO_BLKCIPHER=m
 CONFIG_CRYPTO_HASH=y
 CONFIG_CRYPTO_MANAGER=y
@@ -3023,6 +3157,7 @@ CONFIG_CRYPTO_ECB=m
 CONFIG_CRYPTO_CBC=m
 CONFIG_CRYPTO_PCBC=m
 CONFIG_CRYPTO_LRW=m
+CONFIG_CRYPTO_XTS=m
 # CONFIG_CRYPTO_CRYPTD is not set
 CONFIG_CRYPTO_DES=m
 CONFIG_CRYPTO_FCRYPT=m
@@ -3037,9 +3172,12 @@ CONFIG_CRYPTO_TEA=m
 CONFIG_CRYPTO_ARC4=m
 CONFIG_CRYPTO_KHAZAD=m
 CONFIG_CRYPTO_ANUBIS=m
+CONFIG_CRYPTO_SEED=m
 CONFIG_CRYPTO_DEFLATE=m
 CONFIG_CRYPTO_MICHAEL_MIC=m
 CONFIG_CRYPTO_CRC32C=m
 CONFIG_CRYPTO_CAMELLIA=m
 CONFIG_CRYPTO_TEST=m
+CONFIG_CRYPTO_AUTHENC=m
 CONFIG_CRYPTO_HW=y
+# CONFIG_PPC_CLOCK is not set


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-18 12:34 ppc32: Weird process scheduling behaviour with 2.6.24-rc Michel Dänzer
@ 2008-01-22 14:56 ` Michel Dänzer
  2008-01-23 12:18   ` Michel Dänzer
  0 siblings, 1 reply; 33+ messages in thread
From: Michel Dänzer @ 2008-01-22 14:56 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Ingo Molnar


On Fri, 2008-01-18 at 13:34 +0100, Michel Dänzer wrote:
> This is on a PowerBook5,8.
> 
> In a nutshell, things seem more sluggish in general than with 2.6.23.
> But in particular, processes running at nice levels >0 can get most of
> the CPU cycles available, slowing down processes running at nice level
> 0.

The canonical test case I've come up with is to run an infinite loop
with

sudo -u nobody nice -n 19 sh -c 'while true; do true; done'

This makes my X session (X server running at nice level -1, clients at
0) unusably sluggish (it can even take several seconds to process ctrl-c
to interrupt the infinite loop) with 2.6.24-rc but works as expected
with 2.6.23.

Anybody else seeing this?


> I've seen this since .24-rc5 (the first .24-rc I tried), and it's still
> there with -rc8. I'd be surprised if this kind of behaviour remained
> unfixed for that long if it affected x86, so  I presume it's powerpc
> specific.

Or maybe not... I've bisected this down to the scheduler changes between
df3d80f5a5c74168be42788364d13cf6c83c7b9c/23fd50450a34f2558070ceabb0bfebc1c9604af5 and b5869ce7f68b233ceb81465a7644be0d9a5f3dbb . I'll try and bisect it further, but this is my main work machine, so I can't reboot it too often. I'm CC'ing Ingo in case he has any ideas offhand.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-22 14:56 ` Michel Dänzer
@ 2008-01-23 12:18   ` Michel Dänzer
  2008-01-23 12:36     ` Peter Zijlstra
  2008-01-23 12:42     ` Peter Zijlstra
  0 siblings, 2 replies; 33+ messages in thread
From: Michel Dänzer @ 2008-01-23 12:18 UTC (permalink / raw)
  To: Peter Zijlstra, Ingo Molnar; +Cc: linuxppc-dev


On Tue, 2008-01-22 at 15:56 +0100, Michel Dänzer wrote:
> On Fri, 2008-01-18 at 13:34 +0100, Michel Dänzer wrote:
> > This is on a PowerBook5,8.
> > 
> > In a nutshell, things seem more sluggish in general than with 2.6.23.
> > But in particular, processes running at nice levels >0 can get most of
> > the CPU cycles available, slowing down processes running at nice level
> > 0.
> 
> The canonical test case I've come up with is to run an infinite loop
> with
> 
> sudo -u nobody nice -n 19 sh -c 'while true; do true; done'
> 
> This makes my X session (X server running at nice level -1, clients at
> 0) unusably sluggish (it can even take several seconds to process ctrl-c
> to interrupt the infinite loop) with 2.6.24-rc but works as expected
> with 2.6.23.
> 
> Anybody else seeing this?
> 
> 
> > I've seen this since .24-rc5 (the first .24-rc I tried), and it's still
> > there with -rc8. I'd be surprised if this kind of behaviour remained
> > unfixed for that long if it affected x86, so  I presume it's powerpc
> > specific.
> 
> Or maybe not... I've bisected this down to the scheduler changes
> between
> df3d80f5a5c74168be42788364d13cf6c83c7b9c/23fd50450a34f2558070ceabb0bfebc1c9604af5 and b5869ce7f68b233ceb81465a7644be0d9a5f3dbb .

Finished bisecting now. And the winner is...

810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Mon Oct 15 17:00:14 2007 +0200

    sched: another wakeup_granularity fix
    
    unit mis-match: wakeup_gran was used against a vruntime
    
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

:040000 040000 61242d589b0082a417657807ed6329321340f7f3 bff39e49275324e15f37d2163157733580b7df1a M      kernel


Unfortunately, I don't understand how that can cause the misbehaviour
described above, and 2.6.24-rc8
(667984d9e481e43a930a478c588dced98cb61fea) with the patch below still
shows the problem. Any ideas Peter or Ingo (or anyone, really :)?


diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index da7c061..a7cc22a 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
 	struct task_struct *curr = rq->curr;
 	struct cfs_rq *cfs_rq = task_cfs_rq(curr);
 	struct sched_entity *se = &curr->se, *pse = &p->se;
-	unsigned long gran;
 
 	if (unlikely(rt_prio(p->prio))) {
 		update_rq_clock(rq);
@@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
 		pse = parent_entity(pse);
 	}
 
-	gran = sysctl_sched_wakeup_granularity;
-	if (unlikely(se->load.weight != NICE_0_LOAD))
-		gran = calc_delta_fair(gran, &se->load);
 
-	if (pse->vruntime + gran < se->vruntime)
+	if (pse->vruntime + sysctl_sched_wakeup_granularity < se->vruntime)
 		resched_task(curr);
 }
 


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply related	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-23 12:18   ` Michel Dänzer
@ 2008-01-23 12:36     ` Peter Zijlstra
  2008-01-23 13:14       ` Michel Dänzer
  2008-01-24  8:46       ` Benjamin Herrenschmidt
  2008-01-23 12:42     ` Peter Zijlstra
  1 sibling, 2 replies; 33+ messages in thread
From: Peter Zijlstra @ 2008-01-23 12:36 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: linuxppc-dev, Ingo Molnar


On Wed, 2008-01-23 at 13:18 +0100, Michel Dänzer wrote:
> On Tue, 2008-01-22 at 15:56 +0100, Michel Dänzer wrote:
> > On Fri, 2008-01-18 at 13:34 +0100, Michel Dänzer wrote:
> > > This is on a PowerBook5,8.
> > > 
> > > In a nutshell, things seem more sluggish in general than with 2.6.23.
> > > But in particular, processes running at nice levels >0 can get most of
> > > the CPU cycles available, slowing down processes running at nice level
> > > 0.
> > 
> > The canonical test case I've come up with is to run an infinite loop
> > with
> > 
> > sudo -u nobody nice -n 19 sh -c 'while true; do true; done'
> > 
> > This makes my X session (X server running at nice level -1, clients at
> > 0) unusably sluggish (it can even take several seconds to process ctrl-c
> > to interrupt the infinite loop) with 2.6.24-rc but works as expected
> > with 2.6.23.
> > 
> > Anybody else seeing this?
> > 
> > 
> > > I've seen this since .24-rc5 (the first .24-rc I tried), and it's still
> > > there with -rc8. I'd be surprised if this kind of behaviour remained
> > > unfixed for that long if it affected x86, so  I presume it's powerpc
> > > specific.
> > 
> > Or maybe not... I've bisected this down to the scheduler changes
> > between
> > df3d80f5a5c74168be42788364d13cf6c83c7b9c/23fd50450a34f2558070ceabb0bfebc1c9604af5 and b5869ce7f68b233ceb81465a7644be0d9a5f3dbb .
> 
> Finished bisecting now. And the winner is...
> 
> 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
> commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date:   Mon Oct 15 17:00:14 2007 +0200
> 
>     sched: another wakeup_granularity fix
>     
>     unit mis-match: wakeup_gran was used against a vruntime
>     
>     Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
>     Signed-off-by: Ingo Molnar <mingo@elte.hu>
> 
> :040000 040000 61242d589b0082a417657807ed6329321340f7f3 bff39e49275324e15f37d2163157733580b7df1a M      kernel
> 
> 
> Unfortunately, I don't understand how that can cause the misbehaviour
> described above, and 2.6.24-rc8
> (667984d9e481e43a930a478c588dced98cb61fea) with the patch below still
> shows the problem. Any ideas Peter or Ingo (or anyone, really :)?
> 
> 
> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> index da7c061..a7cc22a 100644
> --- a/kernel/sched_fair.c
> +++ b/kernel/sched_fair.c
> @@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
>  	struct task_struct *curr = rq->curr;
>  	struct cfs_rq *cfs_rq = task_cfs_rq(curr);
>  	struct sched_entity *se = &curr->se, *pse = &p->se;
> -	unsigned long gran;
>  
>  	if (unlikely(rt_prio(p->prio))) {
>  		update_rq_clock(rq);
> @@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
>  		pse = parent_entity(pse);
>  	}
>  
> -	gran = sysctl_sched_wakeup_granularity;
> -	if (unlikely(se->load.weight != NICE_0_LOAD))
> -		gran = calc_delta_fair(gran, &se->load);
>  
> -	if (pse->vruntime + gran < se->vruntime)
> +	if (pse->vruntime + sysctl_sched_wakeup_granularity < se->vruntime)
>  		resched_task(curr);
>  }
>  

Most curious; are you sure its not a bisection problem?

Does ppc32 (or your instance thereof) have a high resolution
sched_clock()?

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-23 12:18   ` Michel Dänzer
  2008-01-23 12:36     ` Peter Zijlstra
@ 2008-01-23 12:42     ` Peter Zijlstra
  2008-01-25  6:54       ` Benjamin Herrenschmidt
  1 sibling, 1 reply; 33+ messages in thread
From: Peter Zijlstra @ 2008-01-23 12:42 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: linuxppc-dev, Ingo Molnar

Another question, do you have:
  CONFIG_FAIR_GROUP_SCHED=y

if so, does flipping that off have any effect?

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-23 12:36     ` Peter Zijlstra
@ 2008-01-23 13:14       ` Michel Dänzer
  2008-01-24  8:18         ` Benjamin Herrenschmidt
  2008-01-24  8:46       ` Benjamin Herrenschmidt
  1 sibling, 1 reply; 33+ messages in thread
From: Michel Dänzer @ 2008-01-23 13:14 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: linuxppc-dev, Ingo Molnar


On Wed, 2008-01-23 at 13:36 +0100, Peter Zijlstra wrote:
> On Wed, 2008-01-23 at 13:18 +0100, Michel Dänzer wrote:
> > 
> > 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
> > commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
> > Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Date:   Mon Oct 15 17:00:14 2007 +0200
> > 
> >     sched: another wakeup_granularity fix
> >     
> >     unit mis-match: wakeup_gran was used against a vruntime
> >     
> >     Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> >     Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > 
> > :040000 040000 61242d589b0082a417657807ed6329321340f7f3 bff39e49275324e15f37d2163157733580b7df1a M      kernel
> > 
> > 
> > Unfortunately, I don't understand how that can cause the misbehaviour
> > described above, and 2.6.24-rc8
> > (667984d9e481e43a930a478c588dced98cb61fea) with the patch below still
> > shows the problem. Any ideas Peter or Ingo (or anyone, really :)?
> > 
> > 
> > diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> > index da7c061..a7cc22a 100644
> > --- a/kernel/sched_fair.c
> > +++ b/kernel/sched_fair.c
> > @@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
> >  	struct task_struct *curr = rq->curr;
> >  	struct cfs_rq *cfs_rq = task_cfs_rq(curr);
> >  	struct sched_entity *se = &curr->se, *pse = &p->se;
> > -	unsigned long gran;
> >  
> >  	if (unlikely(rt_prio(p->prio))) {
> >  		update_rq_clock(rq);
> > @@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
> >  		pse = parent_entity(pse);
> >  	}
> >  
> > -	gran = sysctl_sched_wakeup_granularity;
> > -	if (unlikely(se->load.weight != NICE_0_LOAD))
> > -		gran = calc_delta_fair(gran, &se->load);
> >  
> > -	if (pse->vruntime + gran < se->vruntime)
> > +	if (pse->vruntime + sysctl_sched_wakeup_granularity < se->vruntime)
> >  		resched_task(curr);
> >  }
> >  
> 
> Most curious; are you sure its not a bisection problem?

Quite sure.

> Does ppc32 (or your instance thereof) have a high resolution
> sched_clock()?

I'm not sure (FWIW, we did get support for NO_HZ and HIGH_RES_TIMERS in
2.6.24-rc as well, but playing with these config options and even
reverting the code didn't seem to have any effect), can someone from the
linuxppc-dev list answer this?


> Another question, do you have:
>   CONFIG_FAIR_GROUP_SCHED=y
> 
> if so, does flipping that off have any effect?

I tried both, no difference that I could tell.


Is there any debugging information I could provide from running the test
on kernels built from at and before the change in question?


Thanks,


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-23 13:14       ` Michel Dänzer
@ 2008-01-24  8:18         ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 33+ messages in thread
From: Benjamin Herrenschmidt @ 2008-01-24  8:18 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra


On Wed, 2008-01-23 at 14:14 +0100, Michel Dänzer wrote:
> > Does ppc32 (or your instance thereof) have a high resolution
> > sched_clock()?
> 
> I'm not sure (FWIW, we did get support for NO_HZ and HIGH_RES_TIMERS
> in
> 2.6.24-rc as well, but playing with these config options and even
> reverting the code didn't seem to have any effect), can someone from
> the
> linuxppc-dev list answer this?

We do have a hires sched_clock() based on the processor internal
timebase and scaled to ns. Maybe we screwed something up there ? The
implementation is in arch/powerpc/kernel/timer.c

/*
 * Scheduler clock - returns current time in nanosec units.
 *
 * Note: mulhdu(a, b) (multiply high double unsigned) returns
 * the high 64 bits of a * b, i.e. (a * b) >> 64, where a and b
 * are 64-bit unsigned numbers.
 */
unsigned long long sched_clock(void)
{
	if (__USE_RTC())
		return get_rtc();
	return mulhdu(get_tb() - boot_tb, tb_to_ns_scale) << tb_to_ns_shift;
}

(You can mostly ignore the RTC() case which is the native ns clock of
the old 601 processor.

Ben.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-23 12:36     ` Peter Zijlstra
  2008-01-23 13:14       ` Michel Dänzer
@ 2008-01-24  8:46       ` Benjamin Herrenschmidt
  2008-01-25 10:57         ` Michel Dänzer
  1 sibling, 1 reply; 33+ messages in thread
From: Benjamin Herrenschmidt @ 2008-01-24  8:46 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: linuxppc-dev, Ingo Molnar, Michel Dänzer

Could the fact that our sched_clock() returns utter crap if called
before time_init() explain the problem ? If yes, that's an easy fix.

Ben.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-23 12:42     ` Peter Zijlstra
@ 2008-01-25  6:54       ` Benjamin Herrenschmidt
  2008-01-25  7:03         ` Benjamin Herrenschmidt
  2008-01-25 11:34         ` Michel Dänzer
  0 siblings, 2 replies; 33+ messages in thread
From: Benjamin Herrenschmidt @ 2008-01-25  6:54 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: linuxppc-dev, Ingo Molnar, Michel Dänzer


On Wed, 2008-01-23 at 13:42 +0100, Peter Zijlstra wrote:
> Another question, do you have:
>   CONFIG_FAIR_GROUP_SCHED=y
> 
> if so, does flipping that off have any effect?

Yes.

Here, I do the test of running 4 times the repro-case provided by Michel
with nice 19 and a dd eating CPU with nice 0.

Without this option, I get the dd at 100% and the nice 19 shells down
below it with whatever is left of the CPUs.

With this option, dd gets about 50% of one CPU and the niced processes
still get most of the time.

Ben.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-25  6:54       ` Benjamin Herrenschmidt
@ 2008-01-25  7:03         ` Benjamin Herrenschmidt
  2008-01-25  7:25           ` Benjamin Herrenschmidt
  2008-01-25 11:34         ` Michel Dänzer
  1 sibling, 1 reply; 33+ messages in thread
From: Benjamin Herrenschmidt @ 2008-01-25  7:03 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: linuxppc-dev, Ingo Molnar, Michel Dänzer


On Fri, 2008-01-25 at 17:54 +1100, Benjamin Herrenschmidt wrote:
> 
> Here, I do the test of running 4 times the repro-case provided by Michel
> with nice 19 and a dd eating CPU with nice 0.
> 
> Without this option, I get the dd at 100% and the nice 19 shells down
> below it with whatever is left of the CPUs.
> 
> With this option, dd gets about 50% of one CPU and the niced processes
> still get most of the time.

FYI. This is a 4 way G5 (ppc64)

Ben.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-25  7:03         ` Benjamin Herrenschmidt
@ 2008-01-25  7:25           ` Benjamin Herrenschmidt
  2008-01-25  8:50             ` Peter Zijlstra
  0 siblings, 1 reply; 33+ messages in thread
From: Benjamin Herrenschmidt @ 2008-01-25  7:25 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: linuxppc-dev, Ingo Molnar, Michel Dänzer


On Fri, 2008-01-25 at 18:03 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2008-01-25 at 17:54 +1100, Benjamin Herrenschmidt wrote:
> > 
> > Here, I do the test of running 4 times the repro-case provided by Michel
> > with nice 19 and a dd eating CPU with nice 0.
> > 
> > Without this option, I get the dd at 100% and the nice 19 shells down
> > below it with whatever is left of the CPUs.
> > 
> > With this option, dd gets about 50% of one CPU and the niced processes
> > still get most of the time.
> 
> FYI. This is a 4 way G5 (ppc64)

I also tested responsiveness of X running with or without that option
and with niced CPU eaters in the background (still 4 of them, one per
CPU), and I can confirm Michel observations, it gets very sluggish
(maybe not -as- bad as his but still pretty annoying) with the fair
group scheduler enabled.

Here, X is running with nice=0

Ben.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-25  7:25           ` Benjamin Herrenschmidt
@ 2008-01-25  8:50             ` Peter Zijlstra
  2008-01-26  4:07               ` Srivatsa Vaddagiri
  0 siblings, 1 reply; 33+ messages in thread
From: Peter Zijlstra @ 2008-01-25  8:50 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, Ingo Molnar, Michel Dänzer, vatsa


On Fri, 2008-01-25 at 18:25 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2008-01-25 at 18:03 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2008-01-25 at 17:54 +1100, Benjamin Herrenschmidt wrote:
> > > 
> > > Here, I do the test of running 4 times the repro-case provided by Michel
> > > with nice 19 and a dd eating CPU with nice 0.
> > > 
> > > Without this option, I get the dd at 100% and the nice 19 shells down
> > > below it with whatever is left of the CPUs.
> > > 
> > > With this option, dd gets about 50% of one CPU and the niced processes
> > > still get most of the time.
> > 
> > FYI. This is a 4 way G5 (ppc64)
> 
> I also tested responsiveness of X running with or without that option
> and with niced CPU eaters in the background (still 4 of them, one per
> CPU), and I can confirm Michel observations, it gets very sluggish
> (maybe not -as- bad as his but still pretty annoying) with the fair
> group scheduler enabled.
> 
> Here, X is running with nice=0

Curious, sounds like an issue with the group load balancer, vatsa, any
ideas?

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-24  8:46       ` Benjamin Herrenschmidt
@ 2008-01-25 10:57         ` Michel Dänzer
  0 siblings, 0 replies; 33+ messages in thread
From: Michel Dänzer @ 2008-01-25 10:57 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra

[-- Attachment #1: Type: text/plain, Size: 10888 bytes --]

On Thu, 2008-01-24 at 19:46 +1100, Benjamin Herrenschmidt wrote:
> Could the fact that our sched_clock() returns utter crap if called
> before time_init() explain the problem ?

I don't think so. I've confirmed that it gets called exactly once before
time_init(), but it just returns 0 then, which I don't think should be a
problem.


Also, I'm attaching two copies of /proc/sched_debug obtained with

        sudo -b -u nobody nice -n 19 sh -c 'while true; do true; done'
        && cat /proc/sched_debug >/tmp/sched_debug.before && sleep 20 &&
        cat /proc/sched_debug >/tmp/sched_debug.after && sudo -u nobody
        killall sh

Looking at the diff below, the clock appears quite accurate.


Peter or Ingo, maybe you notice something else odd with these or have
other ideas for what conditions could cause niced processes to have such
an impact on interactivity?


--- /home/michdaen/sched_debug.before	2008-01-25 09:40:34.000000000 +0100
+++ /home/michdaen/sched_debug.after	2008-01-25 09:40:34.000000000 +0100
@@ -1,5 +1,5 @@
 Sched Debug Version: v0.07, 2.6.24-rc8 #4
-now at 204890.233650 msecs
+now at 224908.343840 msecs
   .sysctl_sched_latency                    : 20.000000
   .sysctl_sched_min_granularity            : 4.000000
   .sysctl_sched_wakeup_granularity         : 10.000000
@@ -8,56 +8,56 @@ now at 204890.233650 msecs
   .sysctl_sched_features                   : 7
 
 cpu#0
-  .nr_running                    : 6
-  .load                          : 9971
-  .nr_switches                   : 133199
-  .nr_load_updates               : 80363
-  .nr_uninterruptible            : 2
-  .jiffies                       : 4294872186
+  .nr_running                    : 5
+  .load                          : 4364
+  .nr_switches                   : 142978
+  .nr_load_updates               : 100239
+  .nr_uninterruptible            : 0
+  .jiffies                       : 4294892204
   .next_balance                  : 0.000000
-  .curr->pid                     : 4736
-  .clock                         : 80363.072863
+  .curr->pid                     : 4746
+  .clock                         : 100239.072955
   .idle_clock                    : 0.000000
-  .prev_clock_raw                : 204876.445696
+  .prev_clock_raw                : 224892.259968
   .clock_warps                   : 0
-  .clock_overflows               : 114542
+  .clock_overflows               : 119985
   .clock_deep_idle_events        : 0
   .clock_max_delta               : 0.999936
-  .cpu_load[0]                   : 9971
-  .cpu_load[1]                   : 9948
-  .cpu_load[2]                   : 9733
-  .cpu_load[3]                   : 8396
-  .cpu_load[4]                   : 5996
+  .cpu_load[0]                   : 4364
+  .cpu_load[1]                   : 3979
+  .cpu_load[2]                   : 3443
+  .cpu_load[3]                   : 3331
+  .cpu_load[4]                   : 3268
 
 cfs_rq
-  .exec_clock                    : 60747.682602
-  .MIN_vruntime                  : 35455.964402
-  .min_vruntime                  : 35455.964402
-  .max_vruntime                  : 35455.964402
-  .spread                        : 0.000000
+  .exec_clock                    : 80597.780820
+  .MIN_vruntime                  : 54813.436178
+  .min_vruntime                  : 54813.436178
+  .max_vruntime                  : 54818.646546
+  .spread                        : 5.210368
   .spread0                       : 0.000000
-  .nr_running                    : 2
-  .load                          : 3072
+  .nr_running                    : 3
+  .load                          : 4096
   .bkl_count                     : 0
   .nr_spread_over                : 0
 
 cfs_rq
-  .exec_clock                    : 1.407424
-  .MIN_vruntime                  : 0.000001
-  .min_vruntime                  : 35455.964402
-  .max_vruntime                  : 0.000001
+  .exec_clock                    : 19353.983950
+  .MIN_vruntime                  : 1362837.967264
+  .min_vruntime                  : 54813.436178
+  .max_vruntime                  : 1362837.967264
   .spread                        : 0.000000
   .spread0                       : 0.000000
-  .nr_running                    : 0
-  .load                          : 0
+  .nr_running                    : 1
+  .load                          : 15
   .bkl_count                     : 0
   .nr_spread_over                : 0
 
 cfs_rq
-  .exec_clock                    : 9247.295261
-  .MIN_vruntime                  : 41795.173040
-  .min_vruntime                  : 35455.964402
-  .max_vruntime                  : 41795.173040
+  .exec_clock                    : 9397.906333
+  .MIN_vruntime                  : 41843.822192
+  .min_vruntime                  : 54813.436178
+  .max_vruntime                  : 41843.822192
   .spread                        : 0.000000
   .spread0                       : 0.000000
   .nr_running                    : 2
@@ -68,7 +68,7 @@ cfs_rq
 cfs_rq
   .exec_clock                    : 0.997824
   .MIN_vruntime                  : 0.000001
-  .min_vruntime                  : 35455.964402
+  .min_vruntime                  : 54813.436178
   .max_vruntime                  : 0.000001
   .spread                        : 0.000000
   .spread0                       : 0.000000
@@ -78,9 +78,9 @@ cfs_rq
   .nr_spread_over                : 0
 
 cfs_rq
-  .exec_clock                    : 84.409635
+  .exec_clock                    : 85.106979
   .MIN_vruntime                  : 0.000001
-  .min_vruntime                  : 35455.964402
+  .min_vruntime                  : 54813.436178
   .max_vruntime                  : 0.000001
   .spread                        : 0.000000
   .spread0                       : 0.000000
@@ -90,9 +90,9 @@ cfs_rq
   .nr_spread_over                : 0
 
 cfs_rq
-  .exec_clock                    : 93.714624
+  .exec_clock                    : 94.005568
   .MIN_vruntime                  : 0.000001
-  .min_vruntime                  : 35455.964402
+  .min_vruntime                  : 54813.436178
   .max_vruntime                  : 0.000001
   .spread                        : 0.000000
   .spread0                       : 0.000000
@@ -104,7 +104,7 @@ cfs_rq
 cfs_rq
   .exec_clock                    : 76.941956
   .MIN_vruntime                  : 0.000001
-  .min_vruntime                  : 35455.964402
+  .min_vruntime                  : 54813.436178
   .max_vruntime                  : 0.000001
   .spread                        : 0.000000
   .spread0                       : 0.000000
@@ -114,9 +114,9 @@ cfs_rq
   .nr_spread_over                : 0
 
 cfs_rq
-  .exec_clock                    : 489.676070
+  .exec_clock                    : 496.666022
   .MIN_vruntime                  : 0.000001
-  .min_vruntime                  : 35455.964402
+  .min_vruntime                  : 54813.436178
   .max_vruntime                  : 0.000001
   .spread                        : 0.000000
   .spread0                       : 0.000000
@@ -126,9 +126,9 @@ cfs_rq
   .nr_spread_over                : 0
 
 cfs_rq
-  .exec_clock                    : 6.610804
+  .exec_clock                    : 7.357556
   .MIN_vruntime                  : 0.000001
-  .min_vruntime                  : 35455.964402
+  .min_vruntime                  : 54813.436178
   .max_vruntime                  : 0.000001
   .spread                        : 0.000000
   .spread0                       : 0.000000
@@ -140,7 +140,7 @@ cfs_rq
 cfs_rq
   .exec_clock                    : 9.548608
   .MIN_vruntime                  : 0.000001
-  .min_vruntime                  : 35455.964402
+  .min_vruntime                  : 54813.436178
   .max_vruntime                  : 0.000001
   .spread                        : 0.000000
   .spread0                       : 0.000000
@@ -152,7 +152,7 @@ cfs_rq
 cfs_rq
   .exec_clock                    : 130.004741
   .MIN_vruntime                  : 0.000001
-  .min_vruntime                  : 35455.964402
+  .min_vruntime                  : 54813.436178
   .max_vruntime                  : 0.000001
   .spread                        : 0.000000
   .spread0                       : 0.000000
@@ -164,7 +164,7 @@ cfs_rq
 cfs_rq
   .exec_clock                    : 5.477635
   .MIN_vruntime                  : 0.000001
-  .min_vruntime                  : 35455.964402
+  .min_vruntime                  : 54813.436178
   .max_vruntime                  : 0.000001
   .spread                        : 0.000000
   .spread0                       : 0.000000
@@ -174,24 +174,23 @@ cfs_rq
   .nr_spread_over                : 0
 
 cfs_rq
-  .exec_clock                    : 47873.754074
-  .MIN_vruntime                  : 41804.982498
-  .min_vruntime                  : 35455.964402
-  .max_vruntime                  : 41827.144008
-  .spread                        : 22.161510
+  .exec_clock                    : 48211.939702
+  .MIN_vruntime                  : 42001.676760
+  .min_vruntime                  : 54813.436178
+  .max_vruntime                  : 42013.220923
+  .spread                        : 11.544163
   .spread0                       : 0.000000
-  .nr_running                    : 4
-  .load                          : 7923
+  .nr_running                    : 2
+  .load                          : 2301
   .bkl_count                     : 0
   .nr_spread_over                : 8
 
 runnable tasks:
             task   PID         tree-key  switches  prio     exec-runtime         sum-exec        sum-sleep
 ----------------------------------------------------------------------------------------------------------
-       kblockd/0    61     41804.982498      5110   115     41804.982498        24.883015     78433.943969
-           udevd  1304     41827.144008       686   116     41827.144008       425.666176     63782.106879
-      pbbuttonsd  3878     41805.034397     20351   120     41805.034397       453.425277     41231.848603
-            Xorg  4574     41824.962717     12488   119     41824.962717      4933.764004     24971.603455
-             zsh  4675     41795.173040       631   120     41795.173040       301.572431     24901.348163
-R            cat  4736     41787.850967         0   120     41787.850967         3.696000         0.000000
+      pbbuttonsd  3878     42001.676760     22659   120     42001.676760       506.463055     52940.745088
+            Xorg  4574     42013.220923     15439   119     42013.220923      5168.535269     27513.009418
+             zsh  4675     41843.822192       634   120     41843.822192       302.744207     44763.221535
+              sh  4734   1362837.967264      2791   139   1362837.967264     19352.994638        47.795532
+R            cat  4746     41816.398384         0   120     41816.398384         2.149568         0.000000



-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

[-- Attachment #2: sched_debug.after --]
[-- Type: text/plain, Size: 7574 bytes --]

Sched Debug Version: v0.07, 2.6.24-rc8 #4
now at 224908.343840 msecs
  .sysctl_sched_latency                    : 20.000000
  .sysctl_sched_min_granularity            : 4.000000
  .sysctl_sched_wakeup_granularity         : 10.000000
  .sysctl_sched_batch_wakeup_granularity   : 10.000000
  .sysctl_sched_child_runs_first           : 0.000001
  .sysctl_sched_features                   : 7

cpu#0
  .nr_running                    : 5
  .load                          : 4364
  .nr_switches                   : 142978
  .nr_load_updates               : 100239
  .nr_uninterruptible            : 0
  .jiffies                       : 4294892204
  .next_balance                  : 0.000000
  .curr->pid                     : 4746
  .clock                         : 100239.072955
  .idle_clock                    : 0.000000
  .prev_clock_raw                : 224892.259968
  .clock_warps                   : 0
  .clock_overflows               : 119985
  .clock_deep_idle_events        : 0
  .clock_max_delta               : 0.999936
  .cpu_load[0]                   : 4364
  .cpu_load[1]                   : 3979
  .cpu_load[2]                   : 3443
  .cpu_load[3]                   : 3331
  .cpu_load[4]                   : 3268

cfs_rq
  .exec_clock                    : 80597.780820
  .MIN_vruntime                  : 54813.436178
  .min_vruntime                  : 54813.436178
  .max_vruntime                  : 54818.646546
  .spread                        : 5.210368
  .spread0                       : 0.000000
  .nr_running                    : 3
  .load                          : 4096
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 19353.983950
  .MIN_vruntime                  : 1362837.967264
  .min_vruntime                  : 54813.436178
  .max_vruntime                  : 1362837.967264
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 1
  .load                          : 15
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 9397.906333
  .MIN_vruntime                  : 41843.822192
  .min_vruntime                  : 54813.436178
  .max_vruntime                  : 41843.822192
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 2
  .load                          : 2048
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 0.997824
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 54813.436178
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 85.106979
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 54813.436178
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 94.005568
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 54813.436178
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 76.941956
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 54813.436178
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 496.666022
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 54813.436178
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 7.357556
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 54813.436178
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 9.548608
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 54813.436178
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 130.004741
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 54813.436178
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 5.477635
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 54813.436178
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 48211.939702
  .MIN_vruntime                  : 42001.676760
  .min_vruntime                  : 54813.436178
  .max_vruntime                  : 42013.220923
  .spread                        : 11.544163
  .spread0                       : 0.000000
  .nr_running                    : 2
  .load                          : 2301
  .bkl_count                     : 0
  .nr_spread_over                : 8

runnable tasks:
            task   PID         tree-key  switches  prio     exec-runtime         sum-exec        sum-sleep
----------------------------------------------------------------------------------------------------------
      pbbuttonsd  3878     42001.676760     22659   120     42001.676760       506.463055     52940.745088
            Xorg  4574     42013.220923     15439   119     42013.220923      5168.535269     27513.009418
             zsh  4675     41843.822192       634   120     41843.822192       302.744207     44763.221535
              sh  4734   1362837.967264      2791   139   1362837.967264     19352.994638        47.795532
R            cat  4746     41816.398384         0   120     41816.398384         2.149568         0.000000


[-- Attachment #3: sched_debug.before --]
[-- Type: text/plain, Size: 7662 bytes --]

Sched Debug Version: v0.07, 2.6.24-rc8 #4
now at 204890.233650 msecs
  .sysctl_sched_latency                    : 20.000000
  .sysctl_sched_min_granularity            : 4.000000
  .sysctl_sched_wakeup_granularity         : 10.000000
  .sysctl_sched_batch_wakeup_granularity   : 10.000000
  .sysctl_sched_child_runs_first           : 0.000001
  .sysctl_sched_features                   : 7

cpu#0
  .nr_running                    : 6
  .load                          : 9971
  .nr_switches                   : 133199
  .nr_load_updates               : 80363
  .nr_uninterruptible            : 2
  .jiffies                       : 4294872186
  .next_balance                  : 0.000000
  .curr->pid                     : 4736
  .clock                         : 80363.072863
  .idle_clock                    : 0.000000
  .prev_clock_raw                : 204876.445696
  .clock_warps                   : 0
  .clock_overflows               : 114542
  .clock_deep_idle_events        : 0
  .clock_max_delta               : 0.999936
  .cpu_load[0]                   : 9971
  .cpu_load[1]                   : 9948
  .cpu_load[2]                   : 9733
  .cpu_load[3]                   : 8396
  .cpu_load[4]                   : 5996

cfs_rq
  .exec_clock                    : 60747.682602
  .MIN_vruntime                  : 35455.964402
  .min_vruntime                  : 35455.964402
  .max_vruntime                  : 35455.964402
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 2
  .load                          : 3072
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 1.407424
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 35455.964402
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 9247.295261
  .MIN_vruntime                  : 41795.173040
  .min_vruntime                  : 35455.964402
  .max_vruntime                  : 41795.173040
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 2
  .load                          : 2048
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 0.997824
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 35455.964402
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 84.409635
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 35455.964402
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 93.714624
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 35455.964402
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 76.941956
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 35455.964402
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 489.676070
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 35455.964402
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 6.610804
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 35455.964402
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 9.548608
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 35455.964402
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 130.004741
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 35455.964402
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 5.477635
  .MIN_vruntime                  : 0.000001
  .min_vruntime                  : 35455.964402
  .max_vruntime                  : 0.000001
  .spread                        : 0.000000
  .spread0                       : 0.000000
  .nr_running                    : 0
  .load                          : 0
  .bkl_count                     : 0
  .nr_spread_over                : 0

cfs_rq
  .exec_clock                    : 47873.754074
  .MIN_vruntime                  : 41804.982498
  .min_vruntime                  : 35455.964402
  .max_vruntime                  : 41827.144008
  .spread                        : 22.161510
  .spread0                       : 0.000000
  .nr_running                    : 4
  .load                          : 7923
  .bkl_count                     : 0
  .nr_spread_over                : 8

runnable tasks:
            task   PID         tree-key  switches  prio     exec-runtime         sum-exec        sum-sleep
----------------------------------------------------------------------------------------------------------
       kblockd/0    61     41804.982498      5110   115     41804.982498        24.883015     78433.943969
           udevd  1304     41827.144008       686   116     41827.144008       425.666176     63782.106879
      pbbuttonsd  3878     41805.034397     20351   120     41805.034397       453.425277     41231.848603
            Xorg  4574     41824.962717     12488   119     41824.962717      4933.764004     24971.603455
             zsh  4675     41795.173040       631   120     41795.173040       301.572431     24901.348163
R            cat  4736     41787.850967         0   120     41787.850967         3.696000         0.000000


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-25  6:54       ` Benjamin Herrenschmidt
  2008-01-25  7:03         ` Benjamin Herrenschmidt
@ 2008-01-25 11:34         ` Michel Dänzer
  2008-01-25 15:04           ` Michel Dänzer
  1 sibling, 1 reply; 33+ messages in thread
From: Michel Dänzer @ 2008-01-25 11:34 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra


On Fri, 2008-01-25 at 17:54 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2008-01-23 at 13:42 +0100, Peter Zijlstra wrote:
> > Another question, do you have:
> >   CONFIG_FAIR_GROUP_SCHED=y
> > 
> > if so, does flipping that off have any effect?
> 
> Yes.
> 
> Here, I do the test of running 4 times the repro-case provided by Michel
> with nice 19 and a dd eating CPU with nice 0.
> 
> Without this option, I get the dd at 100% and the nice 19 shells down
> below it with whatever is left of the CPUs.
> 
> With this option, dd gets about 50% of one CPU and the niced processes
> still get most of the time.

Hmm, interesting. As I said before, I thought I had tested with this
disabled and not seen a difference, but I'll try again to confirm.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-25 11:34         ` Michel Dänzer
@ 2008-01-25 15:04           ` Michel Dänzer
  2008-01-25 21:10             ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 33+ messages in thread
From: Michel Dänzer @ 2008-01-25 15:04 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra, vatsa


On Fri, 2008-01-25 at 12:34 +0100, Michel Dänzer wrote:
> On Fri, 2008-01-25 at 17:54 +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2008-01-23 at 13:42 +0100, Peter Zijlstra wrote:
> > > Another question, do you have:
> > >   CONFIG_FAIR_GROUP_SCHED=y
> > > 
> > > if so, does flipping that off have any effect?
> > 
> > Yes.
> > 
> > Here, I do the test of running 4 times the repro-case provided by Michel
> > with nice 19 and a dd eating CPU with nice 0.
> > 
> > Without this option, I get the dd at 100% and the nice 19 shells down
> > below it with whatever is left of the CPUs.
> > 
> > With this option, dd gets about 50% of one CPU and the niced processes
> > still get most of the time.
> 
> Hmm, interesting. As I said before, I thought I had tested with this
> disabled and not seen a difference, but I'll try again to confirm.

So, 2.6.24 final is indeed much better with this disabled, but still not
as good as 2.6.23: While I can reliably move a window again while the
infinite loop is running, it still stutters badly every couple of
seconds. With 2.6.23 this is smooth all the time.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-25 15:04           ` Michel Dänzer
@ 2008-01-25 21:10             ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 33+ messages in thread
From: Benjamin Herrenschmidt @ 2008-01-25 21:10 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra, vatsa


On Fri, 2008-01-25 at 16:04 +0100, Michel Dänzer wrote:
> > Hmm, interesting. As I said before, I thought I had tested with this
> > disabled and not seen a difference, but I'll try again to confirm.
> 
> So, 2.6.24 final is indeed much better with this disabled, but still
> not
> as good as 2.6.23: While I can reliably move a window again while the
> infinite loop is running, it still stutters badly every couple of
> seconds. With 2.6.23 this is smooth all the time.

This is with or without fair group scheduler enabled ?

Ben.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-25  8:50             ` Peter Zijlstra
@ 2008-01-26  4:07               ` Srivatsa Vaddagiri
  2008-01-26  4:13                 ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 33+ messages in thread
From: Srivatsa Vaddagiri @ 2008-01-26  4:07 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ingo Molnar,
	Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=,
	linuxppc-dev

On Fri, Jan 25, 2008 at 09:50:00AM +0100, Peter Zijlstra wrote:
> 
> On Fri, 2008-01-25 at 18:25 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2008-01-25 at 18:03 +1100, Benjamin Herrenschmidt wrote:
> > > On Fri, 2008-01-25 at 17:54 +1100, Benjamin Herrenschmidt wrote:
> > > > 
> > > > Here, I do the test of running 4 times the repro-case provided by Michel
> > > > with nice 19 and a dd eating CPU with nice 0.
> > > > 
> > > > Without this option, I get the dd at 100% and the nice 19 shells down
> > > > below it with whatever is left of the CPUs.
> > > > 
> > > > With this option, dd gets about 50% of one CPU and the niced processes
> > > > still get most of the time.

Ben,
	I presume you had CONFIG_FAIR_USER_SCHED turned on too? Also were the
dd process and the niced processes running under different user ids? If
so, that is expected behavior, that we divide CPU equally among
users first and then among the processes within each user.

> > > FYI. This is a 4 way G5 (ppc64)
> > 
> > I also tested responsiveness of X running with or without that option
> > and with niced CPU eaters in the background (still 4 of them, one per
> > CPU), and I can confirm Michel observations, it gets very sluggish
> > (maybe not -as- bad as his but still pretty annoying) with the fair
> > group scheduler enabled.

When CONFIG_FAIR_GROUP_SCHED (and CONFIG_FAIR_USER_SCHED) is not
enabled, X will be given higher priority for running on CPU when compared to 
other niced tasks. When the above options are turned on, X (running
under root uid) would be given lesser priority to run when compared to other
niced tasks running user different uids. Hence I expect some drop in
interactivity-experience with FAIR_GROUP_SCHED on.

Can you pls let me know if any of these makes a difference:

1. Run niced tasks as root. This would bring X and niced tasks in the
same "scheduler group" domain, which would give X much more CPU power
when compared to niced tasks.

2. Keep the niced tasks running under a non-root uid, but increase root users 
   cpu share.
	# echo 8192 > /sys/kernel/uids/0/cpu_share

   This should bump up root user's priority for running on CPU and also 
   give a better desktop experience.

> > Here, X is running with nice=0
> 
> Curious, sounds like an issue with the group load balancer, vatsa, any
> ideas?

The group scheduler's SMP-load balance in 2.6.24 is not the best it
could be. sched-devel has a better load balancer, which I am presuming
will go into 2.6.25 soon.

In this case, I suspect that's not the issue.  If X and the niced processes are 
running under different uids, this (niced processes getting more cpu power) is 
on expected lines. Will wait for Ben to confirm this. 

-- 
Regards,
vatsa

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-26  4:07               ` Srivatsa Vaddagiri
@ 2008-01-26  4:13                 ` Benjamin Herrenschmidt
  2008-01-26  5:07                   ` Srivatsa Vaddagiri
  2008-01-26  5:07                   ` Srivatsa Vaddagiri
  0 siblings, 2 replies; 33+ messages in thread
From: Benjamin Herrenschmidt @ 2008-01-26  4:13 UTC (permalink / raw)
  To: vatsa; +Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra, Michel Dänzer


On Sat, 2008-01-26 at 09:37 +0530, Srivatsa Vaddagiri wrote:
> 
> Ben,
>         I presume you had CONFIG_FAIR_USER_SCHED turned on too?

Yes. It seems to be automatically turned on whenever FAIR_GROUP is
turned on. Considering how bad the behaviour is for a standard desktop
configuration, I'd be tempted to say to change it to default n.

> Also were the
> dd process and the niced processes running under different user ids? If
> so, that is expected behavior, that we divide CPU equally among
> users first and then among the processes within each user.

They were different users and that behaviour seems to be a very stupid
default behaviour for a desktop machine. Take this situation:

 - X running as root
 - User apps running as "user"
 - Background crap (indexing daemons etc...) running as their own user
or nobody

Unless you can get some kind of grouping based on user sessions
including suid binaries, X etc... I think this shouldn't default y in
Kconfig.

Not that it seems that Michel reported far worse behaviour than what I
saw, including pretty hickup'ish X behaviour even without the fair group
scheduler compared to 2.6.23. It might be because he's running X niced
to -1 (I leave X at 0 and let the scheduler deal with it in general)
though.

> When CONFIG_FAIR_GROUP_SCHED (and CONFIG_FAIR_USER_SCHED) is not
> enabled, X will be given higher priority for running on CPU when compared to 
> other niced tasks. When the above options are turned on, X (running
> under root uid) would be given lesser priority to run when compared to other
> niced tasks running user different uids. Hence I expect some drop in
> interactivity-experience with FAIR_GROUP_SCHED on.
> 
> Can you pls let me know if any of these makes a difference:
> 
> 1. Run niced tasks as root. This would bring X and niced tasks in the
> same "scheduler group" domain, which would give X much more CPU power
> when compared to niced tasks.

I'll dbl check. My tests where indeed done with different users.

> 2. Keep the niced tasks running under a non-root uid, but increase root users 
>    cpu share.
>         # echo 8192 > /sys/kernel/uids/0/cpu_share
> 
>    This should bump up root user's priority for running on CPU and also 
>    give a better desktop experience.

Allright, that's something that might need to be set by default by the
kernel ... as it will take some time to have knowledge of those knobs to
percolate to distros. Too bad you can't do the opposite by default for
"nobody" as there's no standard uid for it.

> The group scheduler's SMP-load balance in 2.6.24 is not the best it
> could be. sched-devel has a better load balancer, which I am presuming
> will go into 2.6.25 soon.
> 
> In this case, I suspect that's not the issue.  If X and the niced processes are 
> running under different uids, this (niced processes getting more cpu power) is 
> on expected lines. Will wait for Ben to confirm this. 

I would suggest turning the fair group scheduler to default n in stable
for now.

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-26  4:13                 ` Benjamin Herrenschmidt
@ 2008-01-26  5:07                   ` Srivatsa Vaddagiri
  2008-01-26  5:15                     ` Benjamin Herrenschmidt
  2008-01-26  5:07                   ` Srivatsa Vaddagiri
  1 sibling, 1 reply; 33+ messages in thread
From: Srivatsa Vaddagiri @ 2008-01-26  5:07 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
	Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=

On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
> > Ben,
> >         I presume you had CONFIG_FAIR_USER_SCHED turned on too?
> 
> Yes. It seems to be automatically turned on whenever FAIR_GROUP is
> turned on. Considering how bad the behaviour is for a standard desktop
> configuration, I'd be tempted to say to change it to default n.

If I recall, CONFIG_FAIR_USER_SCHED was turned on as default at the same
time as CONFIG_FAIR_GROUP_SCHED as a means to flesh out fair-group
scheduler bugs. Also at that time, CONFIG_FAIR_CGROUP_SCHED was not
available in mainline as the second option for grouping tasks.

Going forward, I am of the favor to turn off CONFIG_FAIR_USER_SCHED by default, 
but turning on CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED on by default.

That way all tasks belong to same group by default unless admin explicitly 
creates groups and moves around tasks between them. This will be good for 
desktop user who may choose to keep all tasks in one group by default, but also 
giving him/her the flexibility of exploiting fair-group scheduler by creating 
custom task groups and adjusting their cpu shares (for ex: kernel compile group 
or multi-media group). If someone still needs the fair-user scheduler (as 
provided by CONFIG_FAIR_USER_SCHED), they can still get it with 
CONFIG_FAIR_CGROUP_SCHED by running a daemon [1] that dynamically moves around 
tasks into different task group based on userid.

Ingo/Peter, what do you think?

> > Also were the
> > dd process and the niced processes running under different user ids? If
> > so, that is expected behavior, that we divide CPU equally among
> > users first and then among the processes within each user.
> 
> They were different users and that behaviour seems to be a very stupid
> default behaviour for a desktop machine. Take this situation:
> 
>  - X running as root
>  - User apps running as "user"
>  - Background crap (indexing daemons etc...) running as their own user
> or nobody
> 
> Unless you can get some kind of grouping based on user sessions
> including suid binaries, X etc... I think this shouldn't default y in
> Kconfig.

yes, see above.

> Not that it seems that Michel reported far worse behaviour than what I
> saw, including pretty hickup'ish X behaviour even without the fair group
> scheduler compared to 2.6.23. It might be because he's running X niced
> to -1 (I leave X at 0 and let the scheduler deal with it in general)
> though.

Hmm ..with X niced to -1, it should get more cpu power leading to a
better desktop experience.

Michel,
	You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 
was the cause for this bad behavior. Do you see behavior change (from good->bad)
immediately after applying that patch during your bisect process?

> > 2. Keep the niced tasks running under a non-root uid, but increase root users 
> >    cpu share.
> >         # echo 8192 > /sys/kernel/uids/0/cpu_share
> > 
> >    This should bump up root user's priority for running on CPU and also 
> >    give a better desktop experience.
> 
> Allright, that's something that might need to be set by default by the
> kernel ... as it will take some time to have knowledge of those knobs to
> percolate to distros. Too bad you can't do the opposite by default for
> "nobody" as there's no standard uid for it.
> 
> > The group scheduler's SMP-load balance in 2.6.24 is not the best it
> > could be. sched-devel has a better load balancer, which I am presuming
> > will go into 2.6.25 soon.
> > 
> > In this case, I suspect that's not the issue.  If X and the niced processes are 
> > running under different uids, this (niced processes getting more cpu power) is 
> > on expected lines. Will wait for Ben to confirm this. 
> 
> I would suggest turning the fair group scheduler to default n in stable
> for now.

I would prefer to have CONFIG_FAIR_GROUP_SCHED +
CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
think is the desktop experience with that combination?

Reference:

1. http://article.gmane.org/gmane.linux.kernel/553267


-- 
Regards,
vatsa

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-26  4:13                 ` Benjamin Herrenschmidt
  2008-01-26  5:07                   ` Srivatsa Vaddagiri
@ 2008-01-26  5:07                   ` Srivatsa Vaddagiri
  2008-01-27 16:13                     ` Michel Dänzer
  1 sibling, 1 reply; 33+ messages in thread
From: Srivatsa Vaddagiri @ 2008-01-26  5:07 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
	Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=

On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
> > Ben,
> >         I presume you had CONFIG_FAIR_USER_SCHED turned on too?
> 
> Yes. It seems to be automatically turned on whenever FAIR_GROUP is
> turned on. Considering how bad the behaviour is for a standard desktop
> configuration, I'd be tempted to say to change it to default n.

If I recall, CONFIG_FAIR_USER_SCHED was turned on as default at the same
time as CONFIG_FAIR_GROUP_SCHED as a means to flesh out fair-group
scheduler bugs. Also at that time, CONFIG_FAIR_CGROUP_SCHED was not
available in mainline as the second option for grouping tasks.

Going forward, I am of the favor to turn off CONFIG_FAIR_USER_SCHED by default, 
but turning on CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED on by default.

That way all tasks belong to same group by default unless admin explicitly 
creates groups and moves around tasks between them. This will be good for 
desktop user who may choose to keep all tasks in one group by default, but also 
giving him/her the flexibility of exploiting fair-group scheduler by creating 
custom task groups and adjusting their cpu shares (for ex: kernel compile group 
or multi-media group). If someone still needs the fair-user scheduler (as 
provided by CONFIG_FAIR_USER_SCHED), they can still get it with 
CONFIG_FAIR_CGROUP_SCHED by running a daemon [1] that dynamically moves around 
tasks into different task group based on userid.

Ingo/Peter, what do you think?

> > Also were the
> > dd process and the niced processes running under different user ids? If
> > so, that is expected behavior, that we divide CPU equally among
> > users first and then among the processes within each user.
> 
> They were different users and that behaviour seems to be a very stupid
> default behaviour for a desktop machine. Take this situation:
> 
>  - X running as root
>  - User apps running as "user"
>  - Background crap (indexing daemons etc...) running as their own user
> or nobody
> 
> Unless you can get some kind of grouping based on user sessions
> including suid binaries, X etc... I think this shouldn't default y in
> Kconfig.

yes, see above.

> Not that it seems that Michel reported far worse behaviour than what I
> saw, including pretty hickup'ish X behaviour even without the fair group
> scheduler compared to 2.6.23. It might be because he's running X niced
> to -1 (I leave X at 0 and let the scheduler deal with it in general)
> though.

Hmm ..with X niced to -1, it should get more cpu power leading to a
better desktop experience.

Michel,
	You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 
was the cause for this bad behavior. Do you see behavior change (from good->bad)
immediately after applying that patch during your bisect process?

> > 2. Keep the niced tasks running under a non-root uid, but increase root users 
> >    cpu share.
> >         # echo 8192 > /sys/kernel/uids/0/cpu_share
> > 
> >    This should bump up root user's priority for running on CPU and also 
> >    give a better desktop experience.
> 
> Allright, that's something that might need to be set by default by the
> kernel ... as it will take some time to have knowledge of those knobs to
> percolate to distros. Too bad you can't do the opposite by default for
> "nobody" as there's no standard uid for it.
> 
> > The group scheduler's SMP-load balance in 2.6.24 is not the best it
> > could be. sched-devel has a better load balancer, which I am presuming
> > will go into 2.6.25 soon.
> > 
> > In this case, I suspect that's not the issue.  If X and the niced processes are 
> > running under different uids, this (niced processes getting more cpu power) is 
> > on expected lines. Will wait for Ben to confirm this. 
> 
> I would suggest turning the fair group scheduler to default n in stable
> for now.

I would prefer to have CONFIG_FAIR_GROUP_SCHED +
CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
think is the desktop experience with that combination?

Reference:

1. http://article.gmane.org/gmane.linux.kernel/553267


-- 
Regards,
vatsa

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-26  5:07                   ` Srivatsa Vaddagiri
@ 2008-01-26  5:15                     ` Benjamin Herrenschmidt
  2008-01-26  9:26                       ` Srivatsa Vaddagiri
  0 siblings, 1 reply; 33+ messages in thread
From: Benjamin Herrenschmidt @ 2008-01-26  5:15 UTC (permalink / raw)
  To: vatsa
  Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
	Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=


> > Not that it seems that Michel reported far worse behaviour than what I
> > saw, including pretty hickup'ish X behaviour even without the fair group
> > scheduler compared to 2.6.23. It might be because he's running X niced
> > to -1 (I leave X at 0 and let the scheduler deal with it in general)
> > though.
> 
> Hmm ..with X niced to -1, it should get more cpu power leading to a
> better desktop experience.

It depends as X can end up starving it's own clients, especially with a
compositing manager or other fancy window manager...

> Michel,
> 	You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 
> was the cause for this bad behavior. Do you see behavior change (from good->bad)
> immediately after applying that patch during your bisect process?

Also Michel, double check your .config in both cases.

> I would prefer to have CONFIG_FAIR_GROUP_SCHED +
> CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
> think is the desktop experience with that combination?

I'm going to give that a try but unfortunately, it will have to wait
until I'm back from LCA in a bit more than a week.

Ben.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-26  5:15                     ` Benjamin Herrenschmidt
@ 2008-01-26  9:26                       ` Srivatsa Vaddagiri
  0 siblings, 0 replies; 33+ messages in thread
From: Srivatsa Vaddagiri @ 2008-01-26  9:26 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: linuxppc-dev, Ingo Molnar, Peter Zijlstra,
	=?iso-8859-1?Q?Michel=2ED=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=.=?iso-8859-1?B?QHNub3d5LmluLmlibS5jb20=?=,
	Michel.Dänzer

On Sat, Jan 26, 2008 at 04:15:52PM +1100, Benjamin Herrenschmidt wrote:
> > Michel,
> > 	You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 
> > was the cause for this bad behavior. Do you see behavior change (from good->bad)
> > immediately after applying that patch during your bisect process?
> 
> Also Michel, double check your .config in both cases.

And also Michel whether CONFIG_FAIR_GROUP_SCHED + CONFIG_FAIR_CGROUP_SCHED
gives more or less same desktop exp as !CONFIG_FAIR_GROUP_SCHED pls!

> > I would prefer to have CONFIG_FAIR_GROUP_SCHED +
> > CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
> > think is the desktop experience with that combination?
> 
> I'm going to give that a try but unfortunately, it will have to wait
> until I'm back from LCA in a bit more than a week.

-- 
Regards,
vatsa

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-26  5:07                   ` Srivatsa Vaddagiri
@ 2008-01-27 16:13                     ` Michel Dänzer
  2008-01-28  4:25                       ` Benjamin Herrenschmidt
  2008-01-28  8:50                       ` Peter Zijlstra
  0 siblings, 2 replies; 33+ messages in thread
From: Michel Dänzer @ 2008-01-27 16:13 UTC (permalink / raw)
  To: vatsa; +Cc: Ingo Molnar, Peter Zijlstra, linuxppc-dev


On Sat, 2008-01-26 at 10:39 +0530, Srivatsa Vaddagiri wrote:
> On Sat, Jan 26, 2008 at 03:13:54PM +1100, Benjamin Herrenschmidt wrote:
> 
> > > Also were the dd process and the niced processes running under 
> > > different user ids? If so, that is expected behavior, that we divide 
> > > CPU equally among users first and then among the processes within each user.

Note that in my test case, the niced infinite loop constantly burns
significantly more than 50% of the cycles; X and its clients never need
more than 20% (high estimate) each to move windows smoothly. So even
under the premise above, it should be possible to have smooth
interaction with X while there is a CPU hog in another group, shouldn't
it?


> > Not that it seems that Michel reported far worse behaviour than what I
> > saw, including pretty hickup'ish X behaviour even without the fair group
> > scheduler compared to 2.6.23. It might be because he's running X niced
> > to -1 (I leave X at 0 and let the scheduler deal with it in general)
> > though.
> 
> Hmm ..with X niced to -1, it should get more cpu power leading to a
> better desktop experience.

FWIW, -1 or 0 for X doesn't seem to make any difference for this
problem.

(I've had X at -1 because a long time ago, when it was at 0 some 3D
games could starve it to the point that their input would be delayed)


> Michel,
> 	You had reported that commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 
> was the cause for this bad behavior. 

Well, it may not be the cause, but that's where the hickups with
CONFIG_FAIR_USER_SCHED disabled first manifest themselves, yes.

> Do you see behavior change (from good->bad) immediately after applying that patch 
> during your bisect process?

Yes, confirmed by trying that commit and its parent again.


> > > 1. Run niced tasks as root. This would bring X and niced tasks in the
> > > same "scheduler group" domain, which would give X much more CPU power
> > > when compared to niced tasks.

Running the niced CPU hog as root or my user instead of as nobody didn't
seem to make a difference, maybe because the X session requires
interaction between processes having different uids, and disturbing
either is sufficient.

> > > 2. Keep the niced tasks running under a non-root uid, but increase root users 
> > >    cpu share.
> > >         # echo 8192 > /sys/kernel/uids/0/cpu_share
> > > 
> > >    This should bump up root user's priority for running on CPU and also 
> > >    give a better desktop experience.

I didn't try 8192, but bumping the shares of root and my user up to 4096
didn't seem to help much if at all. Decreasing the share of the user
running the niced CPU hog to 1 resulted in more or less the same
behaviour as  with CONFIG_FAIR_USER_SCHED disabled.

> > > The group scheduler's SMP-load balance in 2.6.24 is not the best it
> > > could be. sched-devel has a better load balancer, which I am presuming
> > > will go into 2.6.25 soon.

FWIW, the scheduler changes merged after 2.6.24 don't seem to help at
all for my test:

With CONFIG_FAIR_USER_SCHED enabled, X still becomes unusable.

With CONFIG_FAIR_USER_SCHED disabled, X remains mostly usable, but there
are still hickups that weren't there with 2.6.23. (BTW, the hickups seem
related to top running in the terminal window I'm trying to move;
without top running, there are no hickups when moving the window. With
2.6.23, there are no hickups even with top running)

Note that my test case is an exaggerated example constructed from worse
(than with 2.6.23) interactive behaviour I've been seeing with my
day-to-day X session. This isn't just a theoretical problem.


> > > In this case, I suspect that's not the issue.  If X and the niced processes are 
> > > running under different uids, this (niced processes getting more cpu power) is 
> > > on expected lines. Will wait for Ben to confirm this. 
> > 
> > I would suggest turning the fair group scheduler to default n in stable
> > for now.
> 
> I would prefer to have CONFIG_FAIR_GROUP_SCHED +
> CONFIG_FAIR_CGROUP_SCHED on by default. Can you pls let me know how you
> think is the desktop experience with that combination?

Seems to be the same as with CONFIG_FAIR_GROUP_SCHED disabled
completely.


In summary, there are two separate problems with similar symptoms, which
had me confused at times:

      * With CONFIG_FAIR_USER_SCHED disabled, there are severe
        interactivity hickups with a niced CPU hog and top running. This
        started with commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8. 
      * With CONFIG_FAIR_USER_SCHED enabled, X becomes basically
        unusable with a niced CPU hog, with or without top running. I
        don't know when this started, possibly when this option was
        first introduced.

I don't personally care too much about the latter problem - I can live
well without that option. But it would be nice if the former problem
could be fixed (and the default changed from  CONFIG_FAIR_USER_SCHED to
CONFIG_FAIR_CGROUP_SCHED) in 2.6.24.x.

FWIW, the patch below (which reverts commit
810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8) restores 2.6.24 interactivity
to the same level as 2.6.23 here with CONFIG_FAIR_USER_SCHED disabled
(my previous report to the contrary was with CONFIG_FAIR_USER_SCHED
enabled because I didn't yet realize the difference it makes), but I
don't know if that's the real fix.


diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index da7c061..a7cc22a 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
 	struct task_struct *curr = rq->curr;
 	struct cfs_rq *cfs_rq = task_cfs_rq(curr);
 	struct sched_entity *se = &curr->se, *pse = &p->se;
-	unsigned long gran;
 
 	if (unlikely(rt_prio(p->prio))) {
 		update_rq_clock(rq);
@@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
 		pse = parent_entity(pse);
 	}
 
-	gran = sysctl_sched_wakeup_granularity;
-	if (unlikely(se->load.weight != NICE_0_LOAD))
-		gran = calc_delta_fair(gran, &se->load);
 
-	if (pse->vruntime + gran < se->vruntime)
+	if (pse->vruntime + sysctl_sched_wakeup_granularity < se->vruntime)
 		resched_task(curr);
 }
 


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply related	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-27 16:13                     ` Michel Dänzer
@ 2008-01-28  4:25                       ` Benjamin Herrenschmidt
  2008-01-28  8:16                         ` Michel Dänzer
  2008-01-28  8:50                       ` Peter Zijlstra
  1 sibling, 1 reply; 33+ messages in thread
From: Benjamin Herrenschmidt @ 2008-01-28  4:25 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: linuxppc-dev, Ingo Molnar, vatsa, Peter Zijlstra


On Sun, 2008-01-27 at 17:13 +0100, Michel Dänzer wrote:
> 
> > Do you see behavior change (from good->bad) immediately after
> applying that patch 
> > during your bisect process?
> 
> Yes, confirmed by trying that commit and its parent again.

Just to be paranoid... can you try with a different gcc version in case
something gets miscompiled ?

Ben.

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-28  4:25                       ` Benjamin Herrenschmidt
@ 2008-01-28  8:16                         ` Michel Dänzer
  0 siblings, 0 replies; 33+ messages in thread
From: Michel Dänzer @ 2008-01-28  8:16 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, Ingo Molnar, vatsa, Peter Zijlstra


On Mon, 2008-01-28 at 15:25 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2008-01-27 at 17:13 +0100, Michel Dänzer wrote:
> > 
> > > Do you see behavior change (from good->bad) immediately after
> > applying that patch 
> > > during your bisect process?
> > 
> > Yes, confirmed by trying that commit and its parent again.
> 
> Just to be paranoid... can you try with a different gcc version in case
> something gets miscompiled ?

Is that really necessary - after all,
810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is related to process wakeup
behaviour?


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-27 16:13                     ` Michel Dänzer
  2008-01-28  4:25                       ` Benjamin Herrenschmidt
@ 2008-01-28  8:50                       ` Peter Zijlstra
  2008-01-28  9:14                         ` Michel Dänzer
  2008-01-28 12:32                         ` Ingo Molnar
  1 sibling, 2 replies; 33+ messages in thread
From: Peter Zijlstra @ 2008-01-28  8:50 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: Ingo Molnar, vatsa, linuxppc-dev


On Sun, 2008-01-27 at 17:13 +0100, Michel Dänzer wrote:

> In summary, there are two separate problems with similar symptoms, which
> had me confused at times:
> 
>       * With CONFIG_FAIR_USER_SCHED disabled, there are severe
>         interactivity hickups with a niced CPU hog and top running. This
>         started with commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8. 

The revert at the bottom causes the wakeup granularity to shrink for +
nice and to grow for - nice. That is, it becomes easier to preempt a +
nice task, and harder to preempt a - nice task.

I think we originally had that; didn't comment it, forgot the reason
changed it because the units didn't match. Another reason might have
been the more difficult preemption of - nice tasks. That might - niced
tasks to cause horrible latencies - Ingo, any recollection?

Are you perhaps running with a very low HZ (HZ=100)? (If wakeup
preemption fails, tick preemption will take over).

Also, could you try lowering:
  /proc/sys/kernel/sched_wakeup_granularity_ns

>       * With CONFIG_FAIR_USER_SCHED enabled, X becomes basically
>         unusable with a niced CPU hog, with or without top running. I
>         don't know when this started, possibly when this option was
>         first introduced.

Srivatsa found an issue that might explain the very bad behaviour under
group scheduling. But I gather you're not at all interested in this
feature?

> FWIW, the patch below (which reverts commit
> 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8) restores 2.6.24 interactivity
> to the same level as 2.6.23 here with CONFIG_FAIR_USER_SCHED disabled
> (my previous report to the contrary was with CONFIG_FAIR_USER_SCHED
> enabled because I didn't yet realize the difference it makes), but I
> don't know if that's the real fix.
> 
> 
> diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
> index da7c061..a7cc22a 100644
> --- a/kernel/sched_fair.c
> +++ b/kernel/sched_fair.c
> @@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
>  	struct task_struct *curr = rq->curr;
>  	struct cfs_rq *cfs_rq = task_cfs_rq(curr);
>  	struct sched_entity *se = &curr->se, *pse = &p->se;
> -	unsigned long gran;
>  
>  	if (unlikely(rt_prio(p->prio))) {
>  		update_rq_clock(rq);
> @@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p)
>  		pse = parent_entity(pse);
>  	}
>  
> -	gran = sysctl_sched_wakeup_granularity;
> -	if (unlikely(se->load.weight != NICE_0_LOAD))
> -		gran = calc_delta_fair(gran, &se->load);
>  
> -	if (pse->vruntime + gran < se->vruntime)
> +	if (pse->vruntime + sysctl_sched_wakeup_granularity < se->vruntime)
>  		resched_task(curr);
>  }

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-28  8:50                       ` Peter Zijlstra
@ 2008-01-28  9:14                         ` Michel Dänzer
  2008-01-28 12:11                           ` Srivatsa Vaddagiri
  2008-01-28 12:32                         ` Ingo Molnar
  1 sibling, 1 reply; 33+ messages in thread
From: Michel Dänzer @ 2008-01-28  9:14 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Ingo Molnar, vatsa, linuxppc-dev


On Mon, 2008-01-28 at 09:50 +0100, Peter Zijlstra wrote:
> On Sun, 2008-01-27 at 17:13 +0100, Michel Dänzer wrote:
> 
> > In summary, there are two separate problems with similar symptoms, which
> > had me confused at times:
> > 
> >       * With CONFIG_FAIR_USER_SCHED disabled, there are severe
> >         interactivity hickups with a niced CPU hog and top running. This
> >         started with commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8. 
> 
> The revert at the bottom causes the wakeup granularity to shrink for +
> nice and to grow for - nice. That is, it becomes easier to preempt a +
> nice task, and harder to preempt a - nice task.

Yeah, that matches my observations. :)

> I think we originally had that; didn't comment it, forgot the reason
> changed it because the units didn't match. Another reason might have
> been the more difficult preemption of - nice tasks. That might - niced
> tasks to cause horrible latencies - Ingo, any recollection?
> 
> Are you perhaps running with a very low HZ (HZ=100)? (If wakeup
> preemption fails, tick preemption will take over).

I haven't had it below 250 since that became an option, and I'm
currently at 1000 (and NO_HZ, but disabling that didn't seem to make a
difference).

> Also, could you try lowering:
>   /proc/sys/kernel/sched_wakeup_granularity_ns

Will try.


> >       * With CONFIG_FAIR_USER_SCHED enabled, X becomes basically
> >         unusable with a niced CPU hog, with or without top running. I
> >         don't know when this started, possibly when this option was
> >         first introduced.
> 
> Srivatsa found an issue that might explain the very bad behaviour under
> group scheduling. But I gather you're not at all interested in this
> feature?

That's right, but it's good to hear you have a lead there as well, and
if you can't find any interested testers, let me know and I'll try.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-28  9:14                         ` Michel Dänzer
@ 2008-01-28 12:11                           ` Srivatsa Vaddagiri
  0 siblings, 0 replies; 33+ messages in thread
From: Srivatsa Vaddagiri @ 2008-01-28 12:11 UTC (permalink / raw)
  To: Michel.=?iso-8859-1?Q?D=E4nzer_=3Cmichel=40tungstengraphics=2Ecom=3E?=
  Cc: Ingo Molnar, Peter Zijlstra, linuxppc-dev

On Mon, Jan 28, 2008 at 10:14:33AM +0100, Michel Dänzer wrote:
> > >       * With CONFIG_FAIR_USER_SCHED enabled, X becomes basically
> > >         unusable with a niced CPU hog, with or without top running. I
> > >         don't know when this started, possibly when this option was
> > >         first introduced.
> > 
> > Srivatsa found an issue that might explain the very bad behaviour under
> > group scheduling. But I gather you're not at all interested in this
> > feature?
> 
> That's right, but it's good to hear you have a lead there as well, and
> if you can't find any interested testers, let me know and I'll try.

Michel,
	Thanks for offering to test! The issue I found wrt preemption latency 
(when FAIR_USER_SCHED is turned on) is explained here:

http://marc.info/?l=linux-kernel&m=120148675326287

Does the patch in that URL help bring FAIR_USER_SCHED interactivity to the same
level as !FAIR_USER_SCHED?

-- 
Regards,
vatsa

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-28  8:50                       ` Peter Zijlstra
  2008-01-28  9:14                         ` Michel Dänzer
@ 2008-01-28 12:32                         ` Ingo Molnar
  2008-01-28 12:53                           ` Peter Zijlstra
  2008-01-28 13:11                           ` Srivatsa Vaddagiri
  1 sibling, 2 replies; 33+ messages in thread
From: Ingo Molnar @ 2008-01-28 12:32 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: linuxppc-dev, Michel Dänzer, vatsa


* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> >       * With CONFIG_FAIR_USER_SCHED disabled, there are severe
> >         interactivity hickups with a niced CPU hog and top running. This
> >         started with commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8. 
> 
> The revert at the bottom causes the wakeup granularity to shrink for + 
> nice and to grow for - nice. That is, it becomes easier to preempt a + 
> nice task, and harder to preempt a - nice task.

i think it would be OK to do half of this: make it easier to preempt a 
+nice task. Michel, do you really need the -nice portion as well? It's 
not a problem to super-preempt positively reniced tasks, but it can be 
quite annoying if negatively reniced tasks have super-slices.

	Ingo

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-28 12:32                         ` Ingo Molnar
@ 2008-01-28 12:53                           ` Peter Zijlstra
  2008-01-28 12:56                             ` Ingo Molnar
  2008-01-28 13:11                           ` Srivatsa Vaddagiri
  1 sibling, 1 reply; 33+ messages in thread
From: Peter Zijlstra @ 2008-01-28 12:53 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linuxppc-dev, Michel Dänzer, vatsa


On Mon, 2008-01-28 at 13:32 +0100, Ingo Molnar wrote:
> * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> 
> > >       * With CONFIG_FAIR_USER_SCHED disabled, there are severe
> > >         interactivity hickups with a niced CPU hog and top running. This
> > >         started with commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8. 
> > 
> > The revert at the bottom causes the wakeup granularity to shrink for + 
> > nice and to grow for - nice. That is, it becomes easier to preempt a + 
> > nice task, and harder to preempt a - nice task.
> 
> i think it would be OK to do half of this: make it easier to preempt a 
> +nice task. Michel, do you really need the -nice portion as well? It's 
> not a problem to super-preempt positively reniced tasks, but it can be 
> quite annoying if negatively reniced tasks have super-slices.

This should do that (unless I need a stronger cup of tea).

---
Index: linux-2.6/kernel/sched_fair.c
===================================================================
--- linux-2.6.orig/kernel/sched_fair.c
+++ linux-2.6/kernel/sched_fair.c
@@ -1106,7 +1106,11 @@ static void check_preempt_wakeup(struct 
 	}
 
 	gran = sysctl_sched_wakeup_granularity;
-	if (unlikely(se->load.weight != NICE_0_LOAD))
+	/*
+	 * More easily preempt - nice tasks, while not making
+	 * it harder for + nice tasks.
+	 */
+	if (unlikely(se->load.weight > NICE_0_LOAD))
 		gran = calc_delta_fair(gran, &se->load);
 
 	if (pse->vruntime + gran < se->vruntime)

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-28 12:53                           ` Peter Zijlstra
@ 2008-01-28 12:56                             ` Ingo Molnar
  2008-01-29 10:14                               ` Michel Dänzer
  0 siblings, 1 reply; 33+ messages in thread
From: Ingo Molnar @ 2008-01-28 12:56 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: linuxppc-dev, Michel Dänzer, vatsa


* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> > i think it would be OK to do half of this: make it easier to preempt 
> > a +nice task. Michel, do you really need the -nice portion as well? 
> > It's not a problem to super-preempt positively reniced tasks, but it 
> > can be quite annoying if negatively reniced tasks have super-slices.
> 
> This should do that (unless I need a stronger cup of tea).

cool - thanks Peter. Michel, could you check Peter's patch, does it 
resolve all the interactivity problems you've been seeing?

	Ingo

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-28 12:32                         ` Ingo Molnar
  2008-01-28 12:53                           ` Peter Zijlstra
@ 2008-01-28 13:11                           ` Srivatsa Vaddagiri
  1 sibling, 0 replies; 33+ messages in thread
From: Srivatsa Vaddagiri @ 2008-01-28 13:11 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linuxppc-dev, Peter Zijlstra, michel

On Mon, Jan 28, 2008 at 01:32:53PM +0100, Ingo Molnar wrote:
> * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> 
> > >       * With CONFIG_FAIR_USER_SCHED disabled, there are severe
> > >         interactivity hickups with a niced CPU hog and top running. This
> > >         started with commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8. 
> > 
> > The revert at the bottom causes the wakeup granularity to shrink for + 
> > nice and to grow for - nice. That is, it becomes easier to preempt a + 
> > nice task, and harder to preempt a - nice task.
> 
> i think it would be OK to do half of this: make it easier to preempt a 
> +nice task.

Hmm .. I doubt whether that would help Michel's case, as he seems to be running
+niced tasks and having problems getting control over his desktop.

Something is basically wrong here ..

> Michel, do you really need the -nice portion as well? It's 
> not a problem to super-preempt positively reniced tasks, but it can be 
> quite annoying if negatively reniced tasks have super-slices.

-- 
Regards,
vatsa

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
  2008-01-28 12:56                             ` Ingo Molnar
@ 2008-01-29 10:14                               ` Michel Dänzer
  0 siblings, 0 replies; 33+ messages in thread
From: Michel Dänzer @ 2008-01-29 10:14 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linuxppc-dev, Peter Zijlstra, vatsa


On Mon, 2008-01-28 at 13:56 +0100, Ingo Molnar wrote: 
> * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> 
> > > i think it would be OK to do half of this: make it easier to preempt 
> > > a +nice task. Michel, do you really need the -nice portion as well? 
> > > It's not a problem to super-preempt positively reniced tasks, but it 
> > > can be quite annoying if negatively reniced tasks have super-slices.
> > 
> > This should do that (unless I need a stronger cup of tea).
> 
> cool - thanks Peter. Michel, could you check Peter's patch, does it 
> resolve all the interactivity problems you've been seeing?

I'm now running with this patch and Srivatsa's patch, and together they
provide good interactivity even with CONFIG_FAIR_USER_SCHED enabled and
the default value of /proc/sys/kernel/sched_wakeup_granularity_ns. :) So
both patches seem to have the expected effect.

/proc/sys/kernel/sched_features contains 7.


Thanks,


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2008-01-29 10:14 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-01-18 12:34 ppc32: Weird process scheduling behaviour with 2.6.24-rc Michel Dänzer
2008-01-22 14:56 ` Michel Dänzer
2008-01-23 12:18   ` Michel Dänzer
2008-01-23 12:36     ` Peter Zijlstra
2008-01-23 13:14       ` Michel Dänzer
2008-01-24  8:18         ` Benjamin Herrenschmidt
2008-01-24  8:46       ` Benjamin Herrenschmidt
2008-01-25 10:57         ` Michel Dänzer
2008-01-23 12:42     ` Peter Zijlstra
2008-01-25  6:54       ` Benjamin Herrenschmidt
2008-01-25  7:03         ` Benjamin Herrenschmidt
2008-01-25  7:25           ` Benjamin Herrenschmidt
2008-01-25  8:50             ` Peter Zijlstra
2008-01-26  4:07               ` Srivatsa Vaddagiri
2008-01-26  4:13                 ` Benjamin Herrenschmidt
2008-01-26  5:07                   ` Srivatsa Vaddagiri
2008-01-26  5:15                     ` Benjamin Herrenschmidt
2008-01-26  9:26                       ` Srivatsa Vaddagiri
2008-01-26  5:07                   ` Srivatsa Vaddagiri
2008-01-27 16:13                     ` Michel Dänzer
2008-01-28  4:25                       ` Benjamin Herrenschmidt
2008-01-28  8:16                         ` Michel Dänzer
2008-01-28  8:50                       ` Peter Zijlstra
2008-01-28  9:14                         ` Michel Dänzer
2008-01-28 12:11                           ` Srivatsa Vaddagiri
2008-01-28 12:32                         ` Ingo Molnar
2008-01-28 12:53                           ` Peter Zijlstra
2008-01-28 12:56                             ` Ingo Molnar
2008-01-29 10:14                               ` Michel Dänzer
2008-01-28 13:11                           ` Srivatsa Vaddagiri
2008-01-25 11:34         ` Michel Dänzer
2008-01-25 15:04           ` Michel Dänzer
2008-01-25 21:10             ` Benjamin Herrenschmidt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).