inux-next: Tree for Apr 27

inux-next: Tree for Apr 27

[Stephen Rothwell]

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

Hi all,

Changes since 20120424:

The net-next tree lost its merge fixup, but gained a conflict against the
net tree.

The wireless-next tree lost its conflict.

The drm tree lost its build failure.

The kvm-ppc tree gained a build failure for which I added a patch.

The tip tree gained a conflict against the security tree.

The xen tree lost its conflict.

The usb tree gained a build failure, so I used the version form
next-20120424.

The staging tree gained conflicts against Linus' and the driver-core
trees.

The dma-buf tree lost its conflicts.

The akpm tree gained a build failure for which I added a patch.

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

We are up to 187 trees (counting Linus' and 26 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (82b7690 Merge branch 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile)
Merging fixes/master (b1a808f Merge branch 'for-next' of git://gitorious.org/kernel-hsi/kernel-hsi)
Merging kbuild-current/rc-fixes (e88aa7b Fix modpost failures in fedora 17)
Merging arm-current/fixes (3545358 ARM: OMAP: fix DMA vs memory ordering)
Merging m68k-current/for-linus (450aed7 m68k/q40: Add missing platform check before registering platform devices)
Merging powerpc-merge/merge (446f6d0 powerpc/mpic: Properly set default triggers)
Merging sparc/master (e9a5ea1 sparc32,leon: add notify_cpu_starting())
Merging net/master (8b6efb7 MAINTAINERS: update sctp maintainer address)
Merging sound-current/for-linus (cff7873 Merge tag 'asoc-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (314489b Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging wireless/master (afa762f mac80211: call ieee80211_mgd_stop() on interface stop)
Merging driver-core.current/driver-core-linus (e816b57 Linux 3.4-rc3)
Merging tty.current/tty-linus (66f75a5 Linux 3.4-rc4)
Merging usb.current/usb-linus (5c22837 USB: cdc-wdm: fix race leading leading to memory corruption)
Merging staging.current/staging-linus (89f21cc staging: ozwpan: Fix bug where kfree is called twice.)
Merging char-misc.current/char-misc-linus (e816b57 Linux 3.4-rc3)
Merging cpufreq-current/fixes (6139b65 Merge branch 'for_3.4/cpufreq' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into fixes)
Merging input-current/for-linus (899c612 Input: synaptics - fix regression with "image sensor" trackpads)
Merging md-current/for-linus (30b8aa9 md: fix possible corruption of array metadata on shutdown.)
Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix)
Merging crypto-current/master (511d63c crypto: talitos - properly lock access to global talitos registers)
Merging ide/master (0ab3d8b cy82c693: fix PCI device selection)
Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6)
Merging sh-current/sh-fixes-for-linus (691c01c arch/sh/drivers/dma/{dma-g2,dmabrg}.c: ensure arguments to request_irq and free_irq are compatible)
Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting)
Merging devicetree-current/devicetree/merge (766644d of/irq: add empty irq_of_parse_and_map() for non-dt builds)
Merging spi-current/spi/merge (39ec0d3 spi/imx: prevent NULL pointer dereference in spi_imx_probe())
Merging gpio-current/gpio/merge (9a5c7d6 gpio/exynos: Fix compiler warning in gpio-samsung.c file)
Merging arm/for-next (a6e6d51 Merge branches 'amba', 'clkdev', 'fixes', 'misc' and 'mmci' into for-next)
Merging arm-perf/for-next/perf (c16fa4f Linux 3.3)
Merging davinci/davinci-next (fe0d422 Linux 3.0-rc6)
Merging samsung/next-samsung (9edb240 ARM: H1940/RX1950: Change default LED triggers)
Merging s5p/for-next (de12e47 Merge branch 'next/board-samsung' into for-next)
Merging xilinx/arm-next (b85a3ef ARM: Xilinx: Adding Xilinx board support)
Merging blackfin/for-linus (35fe2e7 blackfin: update defconfig for bf527-ezkit)
Merging c6x/for-linux-next (c16fa4f Linux 3.3)
Merging cris/for-next (7b91747 cris: Remove old legacy "-traditional" flag from arch-v10/lib/Makefile)
Merging hexagon/linux-next (4bd8193 various Kconfig cleanup and old platform build code removal)
Merging ia64/next (16f2634 [IA64] Normalize return value of chip->irq_set_affinity() method)
Merging m68k/for-next (dd70ca0 m68k/video: Create <asm/vga.h>)
Merging m68knommu/for-next (b97c0bb m68knommu: make sure 2nd FEC eth interface pins are enabled on 5275 ColdFire)
Merging microblaze/next (258f742 modpost: Fix modpost license checking of vmlinux.o)
Merging mips/mips-for-linux-next (e21e529 Merge branch 'fixes-for-linus' into mips-for-linux-next)
Merging openrisc/for-upstream (c88e692 asm-generic: add linux/types.h to cmpxchg.h)
Merging parisc/for-next (c60dc74 Merge branch 'fixes' into for-next)
Merging powerpc/next (0195c00 Merge tag 'split-asm_system_h-for-linus-20120328' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-asm_system)
Merging 4xx/next (0195c00 Merge tag 'split-asm_system_h-for-linus-20120328' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-asm_system)
Merging mpc5xxx/next (09f61ff powerpc: Option FB_FSL_DIU is not really optional for mpc512x)
Merging galak/next (fa1b42b powerpc/qe: Update the SNUM table for MPC8569 Rev2.0)
Merging s390/features (1571bae [S390] crash dump: add missing SMP dependency)
Merging sh/sh-latest (b2212ea sh64: Kill off unused trap_no/error_code from thread_struct.)
Merging sparc-next/master (df2e7f5 sparc32: fix build of pcic)
CONFLICT (content): Merge conflict in arch/sparc/kernel/leon_smp.c
Merging tile/master (44727a2 arch/tile: tilegx PCI root complex support)
Merging unicore32/unicore32 (0994695 Merge branch 'akpm' (aka "Andrew's patch-bomb, take two"))
Merging ceph/master (cd9d9f5 rbd: don't hold spinlock during messenger flush)
Merging cifs/master (28f8881 Use correct conversion specifiers in cifs_show_options)
Merging configfs/linux-next (b930c26 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs)
Merging ecryptfs/next (6cfd4b4 ecryptfs: remove the second argument of k[un]map_atomic())
CONFLICT (content): Merge conflict in fs/ecryptfs/ecryptfs_kernel.h
Merging ext3/for_next (77f0a97 jbd: Write journal superblock with WRITE_FUA after checkpointing)
Merging ext4/dev (57f73c2 ext4: fix handling of journalled quota options)
Merging fuse/for-next (519c604 fuse: optimize fallocate on permanent failure)
Merging gfs2/master (144a4c2 GFS2: Log code fixes)
Merging logfs/master (cd8bfa9 logfs: initialize the number of iovecs in bio)
Merging nfs/linux-next (ca07929 SUNRPC: set per-net PipeFS superblock before notification)
Merging nfsd/nfsd-next (b108fe6 nfsd: trivial: use SEEK_SET instead of 0 in vfs_llseek)
Merging ocfs2/linux-next (9392557 ocfs2: avoid unaligned access to dqc_bitmap)
Merging omfs/for-next (976d167 Linux 3.1-rc9)
Merging squashfs/master (4b0180a Squashfs: add mount time sanity check for block_size and block_log match)
Merging v9fs/for-next (01627d9 Merge branch 'drm-fixes-intel' of git://people.freedesktop.org/~airlied/linux)
Merging ubifs/linux-next (65b3219 UBIFS: remove xattr Kconnfig option)
Merging xfs/for-next (bc236c3 xfs: use shared ilock mode for direct IO writes by default)
Merging vfs/for-next (9448152 sch_atm.c: get rid of poinless extern)
Merging pci/next (96650e8 PCI: move mutex locking out of pci_dev_reset function)
Merging hid/for-next (e3e49c3 Merge branch 'logitech' into for-next)
Merging quilt/i2c (85bb1a8 i2c-dev: Add support for I2C_M_RECV_LEN)
Merging bjdooks-i2c/next-i2c (fc84fe1 Merge branch 'for_3.3/i2c/misc' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into for-33/i2c/omap)
CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-omap.c
Merging i2c-embedded/i2c-embedded/for-next (a6979e5 of/i2c: implement of_find_i2c_adapter_by_node)
Merging quilt/jdelvare-hwmon (e3a9568 hwmon: Add MCP3021 ADC driver)
Merging hwmon-staging/hwmon-next (ede8fc9 hwmon: (ad7314) Remove unused defines, and rename OFFSET to SHIFT)
Merging v4l-dvb/master (2a43f0b Merge /home/v4l/v4l/patchwork)
CONFLICT (content): Merge conflict in drivers/usb/gadget/uvc_queue.c
Merging kbuild/for-next (63ce2ed Merge branch 'kbuild/rc-fixes' into kbuild/for-next)
Merging kconfig/for-next (eae1c36 Merge branch 'kconfig/for-linus-2' into kconfig/for-next)
Merging libata/NEXT (85d6725 libata: make ata_print_id atomic)
Merging infiniband/for-next (754c8d4 Merge branch 'raw-qp' into for-next)
Merging acpi/next (eeaab2d Merge branches 'idle-fix' and 'misc' into release)
Merging cpupowerutils/master (f166033 cpupower tools: add install target to the debug tools' makefiles)
Merging ieee1394/for-next (8527f8e firewire: core: fw_device_refresh(): clean up error handling)
Merging ubi/linux-next (66f75a5 Linux 3.4-rc4)
Merging dlm/next (1b189b8 dlm: last element of dlm_local_addr[] never used)
Merging scsi/for-next (b965030 Merge branch 'misc' into for-next)
Merging target-updates/for-next (bfb79ea target/iscsi: Go back to core allocating data buffer for cmd)
Merging target-merge/for-next-merge (3e6e9e9 sbp-target: Initial merge of firewire/ieee-1394 target mode support)
Merging ibft/linux-next (935a9fe ibft: Fix finding IBFT ACPI table on UEFI)
Merging isci/all (475448a merge: libsas devel rnc-devel fixes)
CONFLICT (content): Merge conflict in include/scsi/libsas.h
CONFLICT (content): Merge conflict in drivers/scsi/libsas/sas_discover.c
Merging slave-dma/next (56cbb3d Merge branch 'fixes' into next)
Merging dmaengine/next (a2bd114 netdma: adding alignment check for NETDMA ops)
Merging net-next/master (a85c9bb Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next)
CONFLICT (content): Merge conflict in drivers/net/ethernet/intel/e1000e/param.c
CONFLICT (content): Merge conflict in drivers/net/ethernet/emulex/benet/be.h
Merging wireless-next/master (94c514f mac80211: Adds clean sdata helper)
Merging bluetooth/master (139437f Bluetooth: Fix EIR data generation for mgmt_device_found)
Merging mtd/master (7b0e67f mtd: docg3 add protection against concurrency)
Merging l2-mtd/master (dc3c67c mtd: fsmc_nand: Add clk_{un}prepare() support)
Merging crypto/master (d788fec crypto, xor: Sanitize checksumming function selection output)
Merging sound/for-next (dbc3096 Merge branch 'topic/misc' into for-next)
Merging sound-asoc/for-next (7126eae Merge branch 'for-3.5' into asoc-next)
Merging cpufreq/next (a7b422c provide disable_cpufreq() function to disable the API.)
Merging quilt/rr (2a22b63 cpumask: remove old cpu_*_map.)
CONFLICT (content): Merge conflict in init/main.c
CONFLICT (content): Merge conflict in drivers/virtio/virtio_balloon.c
CONFLICT (content): Merge conflict in arch/arm/kernel/kprobes.c
Merging input/next (5d06647 Input: use module_pci_driver)
Merging input-mt/for-next (66f75a5 Linux 3.4-rc4)
Merging cgroup/for-next (c4c27fb cgroups: disallow attaching kthreadd or PF_THREAD_BOUND threads)
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
Merging block/for-next (48eee61 Merge branch 'for-3.5/core' into for-next)
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
Merging quilt/device-mapper (025716f Fix a memory leak inadvertently introduced during simplification of cell_release_singleton() in commit 6f94a4c45a6f744383f9f695dde019998db3df55 ("dm thin: fix stacked bi_next usage").)
Merging embedded/master (4744b43 embedded: fix vc_translate operator precedence)
Merging firmware/master (6e03a20 firmware: speed up request_firmware(), v3)
Merging pcmcia/master (80af9e6 pcmcia at91_cf: fix raw gpio number usage)
Merging mmc/mmc-next (0e9f480 mmc: cd-gpio: protect against NULL context in mmc_cd_gpio_free())
Merging kgdb/kgdb-next (3751d3e x86,kgdb: Fix DEBUG_RODATA limitation using text_poke())
Merging slab/for-next (b80b6c0 Merge branch 'slab/next' into for-next)
Merging uclinux/for-next (5e442a4 Revert "proc: fix races against execve() of /proc/PID/fd**")
Merging md/for-next (732f027 MD RAID1: Further conditionalize 'fullsync')
Merging mfd/for-next (c00ba41 mfd: No need to check for the GPIO offset from asic3_gpio_to_irq)
CONFLICT (content): Merge conflict in drivers/mfd/asic3.c
Merging battery/master (5cdd4d7 max17042_battery: Clean up interrupt handling)
Merging drm/drm-next (1b23170 vga: fix build when fbdev is a module)
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_i2c.c
Merging fbdev/fbdev-next (d313a86 i.MX28: Shut down the LCD controller to avoid BootROM sampling bug)
Merging viafb/viafb-next (838ac78 viafb: avoid refresh and mode lookup in set_par)
Merging omap_dss2/for-next (df01d53 OMAPDSS: APPLY: fix clearing shadow dirty flag with manual update)
Merging regulator/for-next (ac971f0 Merge branch 'regulator-drivers' into regulator-next)
Merging security/next (08162e6 Yama: remove an unused variable)
CONFLICT (content): Merge conflict in include/linux/filter.h
Merging selinux/master (c737f82 SELinux: remove unused common_audit_data in flush_unauthorized_files)
Merging lblnet/master (7e27d6e Linux 2.6.35-rc3)
Merging watchdog/master (8fb551c hpwdt: Only BYTE reads/writes to WD Timer port 0x72)
Merging dwmw2-iommu/master (c3b92c8 Linux 3.1)
Merging iommu/next (7aff2d0 Merge branches 'iommu/fixes', 'dma-debug', 'arm/omap' and 'arm/tegra' into next)
Merging osd/linux-next (72749a2 exofs: Cap on the memcpy() size)
Merging jc_docs/docs-next (5c050fb docs: update the development process document)
Merging trivial/for-next (59bf896 Fix "the the" in various Kconfig)
CONFLICT (modify/delete): sound/soc/imx/Kconfig deleted in HEAD and modified in trivial/for-next. Version trivial/for-next of sound/soc/imx/Kconfig left in tree.
$ git rm -f sound/soc/imx/Kconfig
Merging audit/for-next (dcd6c92 Linux 3.3-rc1)
Merging pm/linux-next (2580dbf The file Documentation/power/freezing-of-tasks.txt was still referencing the TIF_FREEZE flag, that was removed by the commit d88e4cb67197d007fb778d62fe17360e970d5bfa(freezer: remove now unused TIF_FREEZE).)
Merging apm/for-next (f283d22 APM: fix deadlock in APM_IOC_SUSPEND ioctl)
Merging fsnotify/for-next (1aec9c0 inotify: automatically restart syscalls)
Merging edac/linux_next (a4b4be3 edac: rename channel_info to rank_info)
Merging edac-amd/for-next (305f1c3 Merge branch '3.3-pci_device_id' into edac-for-next)
Merging devicetree/devicetree/next (0f22dd3 of: Only compile OF_DYNAMIC on PowerPC pseries and iseries)
Merging spi/spi/next (d57a428 spi/devicetree: Move devicetree support code into spi directory)
Merging tip/auto-latest (dc71c17 Merge branch 'timers/urgent')
CONFLICT (content): Merge conflict in arch/x86/Kconfig
Merging rcu/rcu/next (b46dbb4 Merge branches 'barrier.2012.04.25a', 'fixes.2012.04.25a', 'inline.2012.04.25a' and 'srcu.2012.04.25a' into next.2012.04.25a)
Merging cputime/cputime (c3e0ef9 [S390] fix cputime overflow in uptime_proc_show)
Merging uprobes/for-next (0326f5a uprobes/core: Handle breakpoint and singlestep exceptions)
Merging kmemleak/kmemleak (4878677 kmemleak: do not leak object after tree insertion error)
Merging kvm/linux-next (38e8a2d KVM: x86 emulator: fix asm constraint in flush_pending_x87_faults)
CONFLICT (content): Merge conflict in Documentation/feature-removal-schedule.txt
Merging kvm-ppc/kvm-ppc-next (4831570 KVM: PPC: Book3S: Call into C interrupt handlers)
Merging oprofile/for-next (c16fa4f Linux 3.3)
Merging xen/upstream/xen (af3a3ab Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-fixes)
Merging xen-two/linux-next (e300b82 Merge branch 'stable/for-linus-3.4' into linux-next)
Merging xen-pvhvm/linux-next (b056b6a xen: suspend: remove xen_hvm_suspend)
Merging percpu/for-next (adb7950 percpu: fix __this_cpu_{sub,inc,dec}_return() definition)
Merging workqueues/for-next (0976dfc workqueue: Catch more locking problems with flush_work())
Merging drivers-x86/linux-next (e64c9de dell-laptop: Terminate quirks list properly)
Merging hwpoison/hwpoison (46e387b Merge branch 'hwpoison-hugepages' into hwpoison)
Merging sysctl/master (4e474a0 sysctl: protect poll() in entries that may go away)
Merging regmap/for-next (b076764 Merge branch 'regmap-stride' into regmap-next)
Merging hsi/for-next (43139a6 HSI: hsi_char: Update ioctl-number.txt)
Merging driver-core/driver-core-next (a1d26ac Extcon: check for allocation failure)
Merging tty/tty-next (5d1a33f vt: push the tty_lock down into the map handling)
Merging usb/usb-next (b087657 USB: ehci-tegra: remove PORT_RWC_BITS when setting USB_PORT_FEAT_ENABLE)
$ git reset --hard HEAD^
Merging refs/next/20120424/usb
Merging staging/staging-next (db3b9e9 Staging: VME: move VME drivers out of staging)
CONFLICT (content): Merge conflict in drivers/staging/vt6656/ioctl.c
CONFLICT (content): Merge conflict in drivers/staging/line6/driver.c
CONFLICT (content): Merge conflict in drivers/staging/android/Makefile
CONFLICT (content): Merge conflict in drivers/staging/android/Kconfig
CONFLICT (content): Merge conflict in drivers/Makefile
CONFLICT (content): Merge conflict in drivers/Kconfig
Merging char-misc/char-misc-next (9912143 parport: remove unused dead code from lowlevel drivers)
Merging tmem/linux-next (0f1ea93 Merge branch 'stable/frontswap.v14' into linux-next)
Merging writeback/writeback-for-next (4cd9069 fs: remove 8 bytes of padding from struct writeback_control on 64 bit builds)
Merging arm-dt/devicetree/arm-next (ede338f dt: add documentation of ARM dt boot interface)
Merging hwspinlock/linux-next (8b37fcf hwspinlock: add MAINTAINERS entries)
Merging pinctrl/for-next (413ba2e pinctrl: support gpio request deferred probing)
CONFLICT (content): Merge conflict in drivers/pinctrl/core.c
CONFLICT (content): Merge conflict in Documentation/driver-model/devres.txt
Merging tegra/for-next (1de9e51 Merge branch 'for-3.5/defconfig' into for-next)
Merging moduleh/for-sfr (3c5c69b blackfin: fix ifdef fustercluck in mach-bf538/boards/ezkit.c)
Merging vhost/linux-next (33b3aa0 x86: eoi micro-optimization)
CONFLICT (content): Merge conflict in drivers/net/virtio_net.c
Merging kmap_atomic/kmap_atomic (317b6e1 feature-removal-schedule.txt: schedule the deprecated form of kmap_atomic() for removal)
Merging modem-shm/for-next (3cff1cc caif_shm: Add CAIF driver for Shared memory for M7400)
CONFLICT (content): Merge conflict in drivers/Kconfig
Merging memblock/memblock-kill-early_node_map (7bd0b0f memblock: Reimplement memblock allocation using reverse free area iterator)
Merging remoteproc/for-next (e12bc14 remoteproc: s/big switch/lookup table/)
Merging irqdomain/irqdomain/next (e7cc3ac dt: fix twl4030 for non-dt compile on x86)
Merging gpio/gpio/next (f141ed6 gpio: Move DT support code into drivers/gpio)
Merging arm-soc/for-next (4ffcc6e Merge branch 'fixes' into for-next)
CONFLICT (content): Merge conflict in arch/arm/mach-lpc32xx/common.c
Merging kvmtool/master (0333eec kvm tools: Update README for CONFIG_FB_VESA)
Merging dma-mapping/dma-mapping-next (c6b1f07 ARM: integrate CMA with DMA-mapping subsystem)
CONFLICT (content): Merge conflict in arch/x86/include/asm/dma-mapping.h
Merging dma-buf/for-next (66f75a5 Linux 3.4-rc4)
Merging ktest/for-next (648a182 ktest: Allow a test to override REBOOT_ON_SUCCESS)
Merging scsi-post-merge/merge-base:master ()
$ git checkout akpm
Applying: pagemap.h: fix warning about possibly used before init var
Applying: mm: correctly synchronize rss-counters at exit/exec
Applying: mm-correctly-synchronize-rss-counters-at-exit-exec-fix
Applying: mm: set task exit code before complete_vfork_done()
Applying: umem: fix up unplugging
Applying: arch/x86/platform/geode/net5501.c: change active_low to 0 for LED driver
Applying: arch/x86/platform/iris/iris.c: register a platform device and a platform driver
Applying: intel_mid_powerbtn: mark irq as IRQF_NO_SUSPEND
Applying: arch/x86/include/asm/spinlock.h: fix comment
Applying: arch/x86/kernel/apic/io_apic.c: move io_apic_level_ack_pending() inside CONFIG_GENERIC_PENDING_IRQ
Applying: drivers/xen/Kconfig: fix Kconfig layout
Applying: avr32: don't mask signals in the error path
Applying: avr32: use set_current_blocked() in handle_signal/sys_rt_sigreturn
Applying: avr32: use block_sigmask()
Applying: m32r: use set_current_blocked() and block_sigmask()
Applying: m68k: use set_current_blocked() and block_sigmask()
Applying: mn10300: use set_current_blocked() and block_sigmask()
Applying: cpuidle: remove unused hrtimer_peek_ahead_timers() call
Applying: cris: use set_current_blocked() and block_sigmask()
Applying: cris: select GENERIC_ATOMIC64
Applying: x86: use this_cpu_xxx to replace percpu_xxx funcs
Applying: x86-use-this_cpu_xxx-to-replace-percpu_xxx-funcs-fix
Applying: x86: change percpu_read_stable() to this_cpu_read_stable()
Applying: net: use this_cpu_xxx replace percpu_xxx funcs
Applying: percpu: remove percpu_xxx() functions
Applying: percpu-remove-percpu_xxx-functions-fix
Applying: drm/i915: fix integer overflow in i915_gem_execbuffer2()
Applying: drm/i915: fix integer overflow in i915_gem_do_execbuffer()
Applying: timeconst.pl: remove deprecated defined(@array)
Applying: ia64: use set_current_blocked() and block_sigmask()
Applying: microblaze: don't reimplement force_sigsegv()
Applying: microblaze: no need to reset handler if SA_ONESHOT
Applying: microblaze: fix signal masking
Applying: microblaze: use set_current_blocked() and block_sigmask()
Applying: score: don't mask signals if we fail to setup signal stack
Applying: score: use set_current_blocked() and block_sigmask()
Applying: h8300: use set_current_blocked() and block_sigmask()
Applying: unicore32: use block_sigmask()
Applying: connector/userns: replace netlink uses of cap_raised with capable.
Applying: blackfin: use set_current_blocked() and block_sigmask()
Applying: ocfs2: use find_last_bit()
Applying: ocfs2: use bitmap_weight()
Applying: drivers/scsi/ufs: use module_pci_driver
Applying: drivers/scsi/ufs: reverse the ufshcd_is_device_present logic
Applying: drivers/scsi/ufs: fix evaluation of task_failed status
Applying: drivers/scsi/atp870u.c: fix bad use of udelay
Applying: vfs: increment iversion when a file is truncated
Applying: fs: symlink restrictions on sticky directories
Applying: fs: hardlink creation restrictions
Applying: fsnotify: remove unused parameter from send_to_group()
Applying: fsnotify: handle subfiles' perm events
Applying: brlocks/lglocks: cleanups
Applying: mm/memory_failure: let the compiler add the function name
Applying: mm/mempolicy.c: use enum value MPOL_REBIND_ONCE in mpol_rebind_policy()
Applying: mm/hugetlb.c: use long vars instead of int in region_count()
Applying: mm, thp: remove unnecessary ret variable
Applying: mm, thp: allow fallback when pte_alloc_one() fails for huge pmd
Applying: mm: remove swap token code
Applying: mm: vmscan: remove lumpy reclaim
Applying: mm: vmscan: do not stall on writeback during memory compaction
Applying: mm: vmscan: remove reclaim_mode_t
Applying: hugetlb: rename max_hstate to hugetlb_max_hstate
Applying: hugetlbfs: don't use ERR_PTR with VM_FAULT* values
Applying: hugetlbfs: add an inline helper for finding hstate index
Applying: hugetlb: use mmu_gather instead of a temporary linked list for accumulating pages
Applying: hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages-fix
Applying: hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages-fix-fix
Applying: hugetlb: avoid taking i_mmap_mutex in unmap_single_vma() for hugetlb
Applying: hugetlb: simplify migrate_huge_page()
Applying: memcg: add HugeTLB extension
Applying: hugetlb: add charge/uncharge calls for HugeTLB alloc/free
Applying: memcg: track resource index in cftype private
Applying: hugetlbfs: add memcg control files for hugetlbfs
Applying: memcg: use scnprintf instead of sprintf
Applying: hugetlbfs-add-memcg-control-files-for-hugetlbfs-use-scnprintf-instead-of-sprintf-fix
Applying: hugetlbfs: add a list for tracking in-use HugeTLB pages
Applying: memcg: move HugeTLB resource count to parent cgroup on memcg removal
Applying: memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal-fix
Applying: memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal-fix-fix
Applying: hugetlb: migrate memcg info from oldpage to new page during migration
Applying: hugetlb-migrate-memcg-info-from-oldpage-to-new-page-during-migration-fix
Applying: memcg: add memory controller documentation for hugetlb management
Applying: mm: fix off-by-one bug in print_nodes_state()
Applying: mm: use kcalloc() instead of kzalloc() to allocate array
Applying: mm/mmap.c: find_vma(): remove unnecessary if(mm) check
Applying: mm-mmapc-find_vma-remove-unnecessary-ifmm-check-fix
Applying: mm/fork: fix overflow in vma length when copying mmap on clone
Applying: mm/vmstat.c: remov debug fs entries on failure of file creation and made extfrag_debug_root dentry local
Applying: memcg: fix/change behavior of shared anon at moving task
Applying: memcg swap: mem_cgroup_move_swap_account never needs fixup
Applying: memcg swap: use mem_cgroup_uncharge_swap()
Applying: mm/memcg: scanning_global_lru means mem_cgroup_disabled
Applying: mm/memcg: move reclaim_stat into lruvec
Applying: mm: push lru index into shrink_[in]active_list()
Applying: mm-push-lru-index-into-shrink_active_list-fix
Applying: mm: mark mm-inline functions as __always_inline
Applying: mm: remove lru type checks from __isolate_lru_page()
Applying: mm/memcg: kill mem_cgroup_lru_del()
Applying: memcg: mark more functions/variables as static
Applying: memcg: remove unused variable
Applying: memcg: mark stat field of mem_cgroup struct as __percpu
Applying: memcg: remove redundant parentheses
Applying: memcg: make threshold index in the right position
Applying: memcg: revise the position of threshold index while unregistering event
Applying: mm/memcg: use vm_swappiness from target memory cgroup
Applying: security/keys/keyctl.c: suppress memory allocation failure warning
Applying: frv: use set_current_blocked() and block_sigmask()
Applying: um/kernel/trap.c: port OOM changes to handle_page_fault()
Applying: sgi-xp: use lockdep_assert_held()
Applying: drivers/scsi/aha152x.c: remove broken usage of spin_is_locked()
Applying: XFS: fix lock ASSERT on UP
Applying: mm/huge_memory.c: use lockdep_assert_held()
Applying: futex: use lockdep_assert_held() for lock checking
Applying: drivers/net/irda/sir_dev.c: remove spin_is_locked()
Applying: drivers/net/ethernet/smsc/smsc911x.h: use lockdep_assert_held() instead of home grown buggy construct
Applying: spinlocks.txt: add a discussion on why spin_is_locked() is bad
Applying: spinlockstxt-add-a-discussion-on-why-spin_is_locked-is-bad-fix
Applying: include/linux/spinlock.h: add a kerneldoc comment to spin_is_locked() that discourages its use
Applying: checkpatch: check for spin_is_locked()
Applying: CodingStyle: add kmalloc_array() to memory allocators
Applying: parisc: use set_current_blocked() and block_sigmask()
Applying: introduce SIZE_MAX
Applying: sethostname/setdomainname: notify userspace when there is a change in uts_kern_table
Applying: vsprintf: correctly handle width when '#' flag used in %#p format.
Applying: vsprintf-correctly-handle-width-when-flag-used-in-%p-format-checkpatch-fixes
Applying: vsprintf: further optimize decimal conversion
Applying: vsprintf-further-optimize-decimal-conversion-v2
Applying: vsprintf-further-optimize-decimal-conversion-checkpatch-fixes
Applying: hamradio/scc: orphan driver in MAINTAINERS
Applying: MAINTAINERS: remove Alessandro
Applying: blacklight: remove redundant spi driver bus initialization
Applying: lcd: add callbacks for early fb event blank support
Applying: fbdev: add events for early fb event support
Applying: drivers/leds/leds-lp5521.c: fix lp5521_read() error handling
Applying: leds: driver for DA9052/53 PMIC v2
Applying: leds-led-module-for-da9052-53-pmic-v2-fix
Applying: leds: add LED driver for lm3556 chip
Applying: leds-add-led-driver-for-lm3556-chip-checkpatch-fixes
Applying: leds: lm3556: Don't call kfree for the memory allocated by devm_kzalloc
Applying: leds: simple_strtoul() cleanup
Applying: leds: Use kcalloc instead of kzalloc to allocate array
Applying: leds: add new field to led_classdev struct to save activation state
Applying: leds: change existing triggers to use activated flag
Applying: leds: change ledtrig-timer to use activated flag
Applying: include/linux/led-lm3530.h: comment correction about the range of brightness
Applying: drivers/leds/leds-lm3530.c: simplify als configuration on initialization
Applying: leds: heartbeat: stop on shutdown
Applying: leds-heartbeat-stop-on-shutdown-checkpatch-fixes
Applying: list_debug: WARN for adding something already in the list
Applying: lib/test-kstrtox.c: mark const init data with __initconst instead of __initdata
Applying: lib/string_helpers.c: make arrays static
Applying: lib/bitmap.c: fix documentation for scnprintf() functions
Applying: vsprintf: fix %ps on non symbols when using kallsyms
Applying: spinlock_debug: print kallsyms name for lock
Applying: checkpatch: suggest pr_<level> over printk(KERN_<LEVEL>
Applying: rtc/spear: add Device Tree probing capability
Applying: drivers/rtc/rtc-ep93xx.c: convert to use module_platform_driver()
Applying: rtc: add ioctl to get/clear battery low voltage status
Applying: drivers/rtc/rtc-pcf8563.c: add RTC_VL_READ/RTC_VL_CLR ioctl feature
Applying: drivers/rtc/Kconfig: place RTC_DRV_IMXDI and RTC_MXC under "on-CPU RTC drivers"
Applying: rtc: rename CONFIG_RTC_MXC to CONFIG_RTC_DRV_MXC
Applying: rtc-rename-config_rtc_mxc-to-config_rtc_drv_mxc-fix
Applying: rtc: ds1307: remove superfluous initialization
Applying: rtc: ds1307: add trickle charger support
Applying: drivers/rtc/rtc-m41t93.c: don't let get_time() reset M41T93_FLAG_OF
Applying: HPFS: remove PRINTK() macro
Applying: kmod: unexport call_usermodehelper_freeinfo()
Applying: kmod: convert two call sites to call_usermodehelper_fns()
Applying: kmod: move call_usermodehelper_fns() to .c file and unexport all it's helpers
Applying: kmod.c: fix kernel-doc warning
Applying: kmod: avoid deadlock from recursive kmod call
Applying: cred: remove task_is_dead() from __task_cred() validation
Applying: stack usage: add pid to warning printk in check_stack_usage
Applying: proc: clean up /proc/<pid>/environ handling
Applying: proc-clean-up-proc-pid-environ-handling-checkpatch-fixes
Applying: proc: unify ptrace_may_access() locking code
Applying: proc: remove mm_for_maps()
Applying: proc: use mm_access() instead of ptrace_may_access()
Applying: proc: don't do dummy rcu_read_lock/rcu_read_unlock on error path
Applying: proc: pass "fd" by value in /proc/*/{fd,fdinfo} code
Applying: procfs: use more apprioriate types when dumping /proc/N/stat
Applying: proc: use IS_ERR_OR_NULL()
Applying: fork: call complete_vfork_done() after clearing child_tid and flushing rss-counters
Applying: ipc/sem.c: alternatives to preempt_disable()
Applying: ipc/mqueue: cleanup definition names and locations
Applying: ipc/mqueue: switch back to using non-max values on create
Applying: ipc/mqueue: enforce hard limits
Applying: ipc/mqueue: update maximums for the mqueue subsystem
Applying: mqueue: revert bump up DFLT_*MAX
Applying: mqueue: don't use kmalloc with KMALLOC_MAX_SIZE
Applying: mqueue: separate mqueue default value from maximum value
Applying: selftests: add mq_open_tests
Applying: rapidio: add DMA engine support for RIO data transfers
Applying: rapidio/tsi721: add DMA engine support
Applying: eventfd: change int to __u64 in eventfd_signal()
Applying: eventfd-change-int-to-__u64-in-eventfd_signal-fix
Applying: w1: fix ds28e04 build, select CRC16
Applying: aio/vfs: cleanup of rw_copy_check_uvector() and compat_rw_copy_check_uvector()
Applying: sysctl: make kernel.ns_last_pid control dependent on CHECKPOINT_RESTORE
Applying: fs, proc: introduce /proc/<pid>/task/<tid>/children entry
Applying: syscalls, x86: add __NR_kcmp syscall
Applying: syscalls-x86-add-__nr_kcmp-syscall-v8 comment update
Applying: syscalls-x86-add-__nr_kcmp-syscall-v8-comment-update-fix
Applying: c/r: procfs: add arg_start/end, env_start/end and exit_code members to /proc/$pid/stat
Applying: c/r: prctl: extend PR_SET_MM to set up more mm_struct entries
Applying: c/r: prctl: simplify PR_SET_MM on mm::code/data assignment
Applying: c/r: prctl: return -EFAULT instead of -EINVAL in case if underlied VMA is not found
Applying: c/r: prctl: add ability to set new mm_struct::exe_file
Applying: c/r: prctl: update prctl_set_mm_exe_file() after mm->num_exe_file_vmas removal
Applying: c/r: prctl: add ability to get clear_tid_address
Applying: ramoops: use pstore interface
Applying: ramoops: fix printk format warnings
Applying: kconfig: update compression algorithm info
Applying: notify_change(): check that i_mutex is held
Merging akpm (dbbf8c7 notify_change(): check that i_mutex is held)
Applying: ipc/mqueue: using vmalloc requires including vmalloc.h
Applying: KVM/PPC: do not export things twice

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Randy Dunlap]

On 04/26/2012 11:11 PM, Stephen Rothwell wrote:

> Hi all,
> 
> Changes since 20120424:



uml on x86_64 (defconfig):

mm/memcontrol.c:256:30: error: 'HUGE_MAX_HSTATE' undeclared here (not in a function)


-- 
~Randy

Re: inux-next: Tree for Apr 27 (infiniband/hw/ocrdma)

[Randy Dunlap]

On 04/26/2012 11:11 PM, Stephen Rothwell wrote:

> Hi all,
> 
> Changes since 20120424:



when IPV6 is not enabled:

ERROR: "register_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!
ERROR: "unregister_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!




~Randy

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inux-next: Tree for Apr 27 (infiniband/hw/ocrdma)

[Randy Dunlap]

On 04/26/2012 11:11 PM, Stephen Rothwell wrote:

> Hi all,
> 
> Changes since 20120424:



when IPV6 is not enabled:

ERROR: "register_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!
ERROR: "unregister_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!




~Randy

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[David Rientjes]

On Fri, 27 Apr 2012, Randy Dunlap wrote:

> On 04/26/2012 11:11 PM, Stephen Rothwell wrote:
> 
> > Hi all,
> > 
> > Changes since 20120424:
> 
> 
> 
> uml on x86_64 (defconfig):
> 
> mm/memcontrol.c:256:30: error: 'HUGE_MAX_HSTATE' undeclared here (not in a function)
> 

This is because of "memcg: add HugeTLB extension" from -mm.

This patch is legal in C99, I wonder if Andrew would let us get away with 
something like this so there's no a dozen #ifdefs in mm/memcontrol.c?
---
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -39,13 +39,13 @@
 #ifndef __ASSEMBLY__
 #ifdef CONFIG_HUGETLB_PAGE
 extern unsigned int HPAGE_SHIFT;
+#define HUGE_MAX_HSTATE		(MMU_PAGE_COUNT-1)
 #else
 #define HPAGE_SHIFT PAGE_SHIFT
 #endif
 #define HPAGE_SIZE		((1UL) << HPAGE_SHIFT)
 #define HPAGE_MASK		(~(HPAGE_SIZE - 1))
 #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
-#define HUGE_MAX_HSTATE		(MMU_PAGE_COUNT-1)
 #endif
 
 /* We do define AT_SYSINFO_EHDR but don't use the gate mechanism */
diff --git a/arch/tile/include/asm/page.h b/arch/tile/include/asm/page.h
--- a/arch/tile/include/asm/page.h
+++ b/arch/tile/include/asm/page.h
@@ -136,9 +136,8 @@ static inline __attribute_const__ int get_order(unsigned long size)
 
 #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
 
-#define HUGE_MAX_HSTATE		6
-
 #ifdef CONFIG_HUGETLB_PAGE
+#define HUGE_MAX_HSTATE		6
 #define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
 #endif
 
diff --git a/arch/x86/include/asm/page_types.h b/arch/x86/include/asm/page_types.h
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -25,7 +25,9 @@
 #define HPAGE_MASK		(~(HPAGE_SIZE - 1))
 #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
 
+#ifdef CONFIG_HUGETLB_PAGE
 #define HUGE_MAX_HSTATE 2
+#endif
 
 #define PAGE_OFFSET		((unsigned long)__PAGE_OFFSET)
 
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -324,6 +324,7 @@ static inline int hstate_index(struct hstate *h)
 
 #else
 struct hstate {};
+#define HUGE_MAX_HSTATE 0
 #define alloc_huge_page_node(h, nid) NULL
 #define alloc_bootmem_huge_page(h) NULL
 #define hstate_file(f) NULL

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Andrew Morton]

On Fri, 27 Apr 2012 11:44:24 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:

> On Fri, 27 Apr 2012, Randy Dunlap wrote:
> 
> > On 04/26/2012 11:11 PM, Stephen Rothwell wrote:
> > 
> > > Hi all,
> > > 
> > > Changes since 20120424:
> > 
> > 
> > 
> > uml on x86_64 (defconfig):
> > 
> > mm/memcontrol.c:256:30: error: 'HUGE_MAX_HSTATE' undeclared here (not in a function)
> > 
> 
> This is because of "memcg: add HugeTLB extension" from -mm.
> 
> This patch is legal in C99, I wonder if Andrew would let us get away with 
> something like this so there's no a dozen #ifdefs in mm/memcontrol.c?
> ---
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -39,13 +39,13 @@
>  #ifndef __ASSEMBLY__
>  #ifdef CONFIG_HUGETLB_PAGE
>  extern unsigned int HPAGE_SHIFT;
> +#define HUGE_MAX_HSTATE		(MMU_PAGE_COUNT-1)
>  #else
>  #define HPAGE_SHIFT PAGE_SHIFT
>  #endif
>  #define HPAGE_SIZE		((1UL) << HPAGE_SHIFT)
>  #define HPAGE_MASK		(~(HPAGE_SIZE - 1))
>  #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
> -#define HUGE_MAX_HSTATE		(MMU_PAGE_COUNT-1)
>  #endif
>  
>  /* We do define AT_SYSINFO_EHDR but don't use the gate mechanism */
> diff --git a/arch/tile/include/asm/page.h b/arch/tile/include/asm/page.h
> --- a/arch/tile/include/asm/page.h
> +++ b/arch/tile/include/asm/page.h
> @@ -136,9 +136,8 @@ static inline __attribute_const__ int get_order(unsigned long size)
>  
>  #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
>  
> -#define HUGE_MAX_HSTATE		6
> -
>  #ifdef CONFIG_HUGETLB_PAGE
> +#define HUGE_MAX_HSTATE		6
>  #define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
>  #endif
>  
> diff --git a/arch/x86/include/asm/page_types.h b/arch/x86/include/asm/page_types.h
> --- a/arch/x86/include/asm/page_types.h
> +++ b/arch/x86/include/asm/page_types.h
> @@ -25,7 +25,9 @@
>  #define HPAGE_MASK		(~(HPAGE_SIZE - 1))
>  #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
>  
> +#ifdef CONFIG_HUGETLB_PAGE
>  #define HUGE_MAX_HSTATE 2
> +#endif
>  
>  #define PAGE_OFFSET		((unsigned long)__PAGE_OFFSET)
>  
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -324,6 +324,7 @@ static inline int hstate_index(struct hstate *h)
>  
>  #else
>  struct hstate {};
> +#define HUGE_MAX_HSTATE 0
>  #define alloc_huge_page_node(h, nid) NULL
>  #define alloc_bootmem_huge_page(h) NULL
>  #define hstate_file(f) NULL

Seems reasonable.  But the CONFIG_HUGETLB_PAGE=y,
CONFIG_MEM_RES_CTLR_HUGETLB=n combination will cause unneeded code
generation and space consumption in memcontrol.c.

I wonder if we can additionally do, within memcontrol.c:

/*
 * Nice comment goes here
 */
#ifdef CONFIG_MEM_RES_CTLR_HUGETLB
#define HUGE_MAX_HSTATE_FOO HUGE_MAX_HSTATE
#else
#define HUGE_MAX_HSTATE_FOO 0
#endif

and s/HUGE_MAX_HSTATE/HUGE_MAX_HSTATE_FOO/ in that file.

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[David Rientjes]

On Fri, 27 Apr 2012, Andrew Morton wrote:

> Seems reasonable.  But the CONFIG_HUGETLB_PAGE=y,
> CONFIG_MEM_RES_CTLR_HUGETLB=n combination will cause unneeded code
> generation and space consumption in memcontrol.c.
> 
> I wonder if we can additionally do, within memcontrol.c:
> 
> /*
>  * Nice comment goes here
>  */
> #ifdef CONFIG_MEM_RES_CTLR_HUGETLB
> #define HUGE_MAX_HSTATE_FOO HUGE_MAX_HSTATE
> #else
> #define HUGE_MAX_HSTATE_FOO 0
> #endif
> 
> and s/HUGE_MAX_HSTATE/HUGE_MAX_HSTATE_FOO/ in that file.
> 

I haven't looked at the hugetlb memcg controller in-depth (yet), but I 
really think we should start considering breaking things like this off 
into its own cgroup.  The hugetlb extension seems like something that 
could be easily separtated, but perhaps I'm saying "easily" because I 
haven't looked at the implementation.

mm/memcontrol.c in linux-next is 5877 lines and, if history is any guide, 
it's going to continue growing.

If the hugetlb usage isn't charged against the memcg's 
memory.usage_in_bytes like thp is, then I really think it should be its 
own cgroup.  From the hugetlb perspective absent any cgroups, things like 
hstates (since we're talking about HUGE_MAX_HSTATE) are global resources 
and so you'd need to preallocate these on the command line or via sysfs 
before you could mmap them.  So if my assumption that the hugetlb memcg 
controller is only governing these global resources and charging a set of 
tasks for what they use, then it really has no business in mm/memcontrol.c 
to begin with, in my opinion.

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Andrew Morton]

On Fri, 27 Apr 2012 14:27:13 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:

> On Fri, 27 Apr 2012, Andrew Morton wrote:
> 
> > Seems reasonable.  But the CONFIG_HUGETLB_PAGE=y,
> > CONFIG_MEM_RES_CTLR_HUGETLB=n combination will cause unneeded code
> > generation and space consumption in memcontrol.c.
> > 
> > I wonder if we can additionally do, within memcontrol.c:
> > 
> > /*
> >  * Nice comment goes here
> >  */
> > #ifdef CONFIG_MEM_RES_CTLR_HUGETLB
> > #define HUGE_MAX_HSTATE_FOO HUGE_MAX_HSTATE
> > #else
> > #define HUGE_MAX_HSTATE_FOO 0
> > #endif
> > 
> > and s/HUGE_MAX_HSTATE/HUGE_MAX_HSTATE_FOO/ in that file.
> > 
> 
> I haven't looked at the hugetlb memcg controller in-depth (yet), but I 
> really think we should start considering breaking things like this off 
> into its own cgroup.  The hugetlb extension seems like something that 
> could be easily separtated, but perhaps I'm saying "easily" because I 
> haven't looked at the implementation.
> 
> mm/memcontrol.c in linux-next is 5877 lines and, if history is any guide, 
> it's going to continue growing.
> 
> If the hugetlb usage isn't charged against the memcg's 
> memory.usage_in_bytes like thp is, then I really think it should be its 
> own cgroup.  From the hugetlb perspective absent any cgroups, things like 
> hstates (since we're talking about HUGE_MAX_HSTATE) are global resources 
> and so you'd need to preallocate these on the command line or via sysfs 
> before you could mmap them.  So if my assumption that the hugetlb memcg 
> controller is only governing these global resources and charging a set of 
> tasks for what they use, then it really has no business in mm/memcontrol.c 
> to begin with, in my opinion.

Minor matter: that's non-responsive to my suggestion.

Major matter: that's a big fat nack to this patchset:

hugetlb-rename-max_hstate-to-hugetlb_max_hstate.patch
hugetlbfs-dont-use-err_ptr-with-vm_fault-values.patch
hugetlbfs-add-an-inline-helper-for-finding-hstate-index.patch
hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages.patch
hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages-fix.patch
hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages-fix-fix.patch
hugetlb-avoid-taking-i_mmap_mutex-in-unmap_single_vma-for-hugetlb.patch
hugetlb-simplify-migrate_huge_page.patch
memcg-add-hugetlb-extension.patch
memcg-add-hugetlb-extension-fix.patch
hugetlb-add-charge-uncharge-calls-for-hugetlb-alloc-free.patch
memcg-track-resource-index-in-cftype-private.patch
hugetlbfs-add-memcg-control-files-for-hugetlbfs.patch
hugetlbfs-add-memcg-control-files-for-hugetlbfs-use-scnprintf-instead-of-sprintf.patch
hugetlbfs-add-memcg-control-files-for-hugetlbfs-use-scnprintf-instead-of-sprintf-fix.patch
hugetlbfs-add-a-list-for-tracking-in-use-hugetlb-pages.patch
memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal.patch
memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal-fix.patch
memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal-fix-fix.patch
hugetlb-migrate-memcg-info-from-oldpage-to-new-page-during-migration.patch
hugetlb-migrate-memcg-info-from-oldpage-to-new-page-during-migration-fix.patch
memcg-add-memory-controller-documentation-for-hugetlb-management.patch

so please take it up at a convenient time, in the appropriate
thread, with the appropriate cc's!

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[David Rientjes]

On Fri, 27 Apr 2012, Andrew Morton wrote:

> > > Seems reasonable.  But the CONFIG_HUGETLB_PAGE=y,
> > > CONFIG_MEM_RES_CTLR_HUGETLB=n combination will cause unneeded code
> > > generation and space consumption in memcontrol.c.
> > > 
> > > I wonder if we can additionally do, within memcontrol.c:
> > > 
> > > /*
> > >  * Nice comment goes here
> > >  */
> > > #ifdef CONFIG_MEM_RES_CTLR_HUGETLB
> > > #define HUGE_MAX_HSTATE_FOO HUGE_MAX_HSTATE
> > > #else
> > > #define HUGE_MAX_HSTATE_FOO 0
> > > #endif
> > > 
> > > and s/HUGE_MAX_HSTATE/HUGE_MAX_HSTATE_FOO/ in that file.
> > > 
> > 
> > I haven't looked at the hugetlb memcg controller in-depth (yet), but I 
> > really think we should start considering breaking things like this off 
> > into its own cgroup.  The hugetlb extension seems like something that 
> > could be easily separtated, but perhaps I'm saying "easily" because I 
> > haven't looked at the implementation.
> > 
> > mm/memcontrol.c in linux-next is 5877 lines and, if history is any guide, 
> > it's going to continue growing.
> > 
> > If the hugetlb usage isn't charged against the memcg's 
> > memory.usage_in_bytes like thp is, then I really think it should be its 
> > own cgroup.  From the hugetlb perspective absent any cgroups, things like 
> > hstates (since we're talking about HUGE_MAX_HSTATE) are global resources 
> > and so you'd need to preallocate these on the command line or via sysfs 
> > before you could mmap them.  So if my assumption that the hugetlb memcg 
> > controller is only governing these global resources and charging a set of 
> > tasks for what they use, then it really has no business in mm/memcontrol.c 
> > to begin with, in my opinion.
> 
> Minor matter: that's non-responsive to my suggestion.
> 

If it's moved to a new cgroup then we can just go back to the original 
point that I made as was trying to avoid: adding #ifdefs all over 
mm/memcontrol.c in a dozen or so places.  A mm/hugetlbcg.c would only be 
built, natually, when we have "depends on HUGETLB_PAGE" and 
linux/hugetlb.h takes care of the rest (setting HUGE_MAX_HSTATE for archs 
that don't define it themselves, in other words only one hugepage size).

> Major matter: that's a big fat nack to this patchset:
> 
> hugetlb-rename-max_hstate-to-hugetlb_max_hstate.patch
> hugetlbfs-dont-use-err_ptr-with-vm_fault-values.patch
> hugetlbfs-add-an-inline-helper-for-finding-hstate-index.patch
> hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages.patch
> hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages-fix.patch
> hugetlb-use-mmu_gather-instead-of-a-temporary-linked-list-for-accumulating-pages-fix-fix.patch
> hugetlb-avoid-taking-i_mmap_mutex-in-unmap_single_vma-for-hugetlb.patch
> hugetlb-simplify-migrate_huge_page.patch
> memcg-add-hugetlb-extension.patch
> memcg-add-hugetlb-extension-fix.patch
> hugetlb-add-charge-uncharge-calls-for-hugetlb-alloc-free.patch
> memcg-track-resource-index-in-cftype-private.patch
> hugetlbfs-add-memcg-control-files-for-hugetlbfs.patch
> hugetlbfs-add-memcg-control-files-for-hugetlbfs-use-scnprintf-instead-of-sprintf.patch
> hugetlbfs-add-memcg-control-files-for-hugetlbfs-use-scnprintf-instead-of-sprintf-fix.patch
> hugetlbfs-add-a-list-for-tracking-in-use-hugetlb-pages.patch
> memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal.patch
> memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal-fix.patch
> memcg-move-hugetlb-resource-count-to-parent-cgroup-on-memcg-removal-fix-fix.patch
> hugetlb-migrate-memcg-info-from-oldpage-to-new-page-during-migration.patch
> hugetlb-migrate-memcg-info-from-oldpage-to-new-page-during-migration-fix.patch
> memcg-add-memory-controller-documentation-for-hugetlb-management.patch
> 
> so please take it up at a convenient time, in the appropriate
> thread, with the appropriate cc's!
> 

No problem, and in the meantime, maybe Aneesh can talk about the 
ramifications of moving this out of memcg?

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Andrew Morton]

On Fri, 27 Apr 2012 16:14:52 -0700 (PDT)
David Rientjes <rientjes@google.com> wrote:

> > Minor matter: that's non-responsive to my suggestion.
> > 
> 
> If it's moved to a new cgroup then we can just go back to the original 
> point that I made as was trying to avoid: adding #ifdefs all over 
> mm/memcontrol.c in a dozen or so places.  A mm/hugetlbcg.c would only be 
> built, natually, when we have "depends on HUGETLB_PAGE" and 
> linux/hugetlb.h takes care of the rest (setting HUGE_MAX_HSTATE for archs 
> that don't define it themselves, in other words only one hugepage size).

And if it isn't moved to a new cgroup then your
memcg-add-hugetlb-extension-fix.patch is suboptimal.  Why is this so
hard?

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[David Rientjes]

On Fri, 27 Apr 2012, Andrew Morton wrote:

> > > Minor matter: that's non-responsive to my suggestion.
> > > 
> > 
> > If it's moved to a new cgroup then we can just go back to the original 
> > point that I made as was trying to avoid: adding #ifdefs all over 
> > mm/memcontrol.c in a dozen or so places.  A mm/hugetlbcg.c would only be 
> > built, natually, when we have "depends on HUGETLB_PAGE" and 
> > linux/hugetlb.h takes care of the rest (setting HUGE_MAX_HSTATE for archs 
> > that don't define it themselves, in other words only one hugepage size).
> 
> And if it isn't moved to a new cgroup then your
> memcg-add-hugetlb-extension-fix.patch is suboptimal.  Why is this so
> hard?
> 

It _should_ be moved to a new cgroup: there's no reason why someone should 
need to enable memcg (and incur ~1% of metadata overhead that comes with 
it) if they just want to seperate a global hugepage pool amongst a set of 
tasks.  Perhaps Aneesh has a reasoning behind this, I dunno.

And yes, memcg-add-hugetlb-extension-fix.patch is a build fix for the 
linux-next breakage.  If it's seperated out to mm/hugetlbcg.c, this is all 
irrelevant.  I'd like to determine the direction of this feature before 
proposing any fixes for build breakage.  In other words, if 
memcg-add-hugetlb-extension.patch is rewritten then 
memcg-add-hugetlb-extension-fix.patch is useless.

Re: inux-next: Tree for Apr 27 (infiniband/hw/ocrdma)

[Roland Dreier]

On Fri, Apr 27, 2012 at 9:56 AM, Randy Dunlap <rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org> wrote:
> when IPV6 is not enabled:
>
> ERROR: "register_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!
> ERROR: "unregister_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!

Thanks, I'll take care of this (probably just wrap those calls in a
check if ipv6 is enabled).

 - R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: inux-next: Tree for Apr 27 (infiniband/hw/ocrdma)

[Roland Dreier]

On Fri, Apr 27, 2012 at 9:56 AM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> when IPV6 is not enabled:
>
> ERROR: "register_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!
> ERROR: "unregister_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!

Thanks, I'll take care of this (probably just wrap those calls in a
check if ipv6 is enabled).

 - R.

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Randy Dunlap]

On 04/27/2012 11:44 AM, David Rientjes wrote:

> On Fri, 27 Apr 2012, Randy Dunlap wrote:
> 
>> On 04/26/2012 11:11 PM, Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> Changes since 20120424:
>>
>>
>>
>> uml on x86_64 (defconfig):
>>
>> mm/memcontrol.c:256:30: error: 'HUGE_MAX_HSTATE' undeclared here (not in a function)
>>
> 
> This is because of "memcg: add HugeTLB extension" from -mm.
> 
> This patch is legal in C99, I wonder if Andrew would let us get away with 
> something like this so there's no a dozen #ifdefs in mm/memcontrol.c?


Well, that works, but no S-O-B and no Ack.


> ---
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -39,13 +39,13 @@
>  #ifndef __ASSEMBLY__
>  #ifdef CONFIG_HUGETLB_PAGE
>  extern unsigned int HPAGE_SHIFT;
> +#define HUGE_MAX_HSTATE		(MMU_PAGE_COUNT-1)
>  #else
>  #define HPAGE_SHIFT PAGE_SHIFT
>  #endif
>  #define HPAGE_SIZE		((1UL) << HPAGE_SHIFT)
>  #define HPAGE_MASK		(~(HPAGE_SIZE - 1))
>  #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
> -#define HUGE_MAX_HSTATE		(MMU_PAGE_COUNT-1)
>  #endif
>  
>  /* We do define AT_SYSINFO_EHDR but don't use the gate mechanism */
> diff --git a/arch/tile/include/asm/page.h b/arch/tile/include/asm/page.h
> --- a/arch/tile/include/asm/page.h
> +++ b/arch/tile/include/asm/page.h
> @@ -136,9 +136,8 @@ static inline __attribute_const__ int get_order(unsigned long size)
>  
>  #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
>  
> -#define HUGE_MAX_HSTATE		6
> -
>  #ifdef CONFIG_HUGETLB_PAGE
> +#define HUGE_MAX_HSTATE		6
>  #define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
>  #endif
>  
> diff --git a/arch/x86/include/asm/page_types.h b/arch/x86/include/asm/page_types.h
> --- a/arch/x86/include/asm/page_types.h
> +++ b/arch/x86/include/asm/page_types.h
> @@ -25,7 +25,9 @@
>  #define HPAGE_MASK		(~(HPAGE_SIZE - 1))
>  #define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
>  
> +#ifdef CONFIG_HUGETLB_PAGE
>  #define HUGE_MAX_HSTATE 2
> +#endif
>  
>  #define PAGE_OFFSET		((unsigned long)__PAGE_OFFSET)
>  
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -324,6 +324,7 @@ static inline int hstate_index(struct hstate *h)
>  
>  #else
>  struct hstate {};
> +#define HUGE_MAX_HSTATE 0
>  #define alloc_huge_page_node(h, nid) NULL
>  #define alloc_bootmem_huge_page(h) NULL
>  #define hstate_file(f) NULL



-- 
~Randy

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Aneesh Kumar K.V]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Fri, 27 Apr 2012 14:27:13 -0700 (PDT)
> David Rientjes <rientjes@google.com> wrote:
>
>> On Fri, 27 Apr 2012, Andrew Morton wrote:
>> 
>> > Seems reasonable.  But the CONFIG_HUGETLB_PAGE=y,
>> > CONFIG_MEM_RES_CTLR_HUGETLB=n combination will cause unneeded code
>> > generation and space consumption in memcontrol.c.
>> > 
>> > I wonder if we can additionally do, within memcontrol.c:
>> > 
>> > /*
>> >  * Nice comment goes here
>> >  */
>> > #ifdef CONFIG_MEM_RES_CTLR_HUGETLB
>> > #define HUGE_MAX_HSTATE_FOO HUGE_MAX_HSTATE
>> > #else
>> > #define HUGE_MAX_HSTATE_FOO 0
>> > #endif
>> > 
>> > and s/HUGE_MAX_HSTATE/HUGE_MAX_HSTATE_FOO/ in that file.
>> > 
>> 
>> I haven't looked at the hugetlb memcg controller in-depth (yet), but I 
>> really think we should start considering breaking things like this off 
>> into its own cgroup.  The hugetlb extension seems like something that 
>> could be easily separtated, but perhaps I'm saying "easily" because I 
>> haven't looked at the implementation.
>> 
>> mm/memcontrol.c in linux-next is 5877 lines and, if history is any guide, 
>> it's going to continue growing.
>> 
>> If the hugetlb usage isn't charged against the memcg's 
>> memory.usage_in_bytes like thp is, then I really think it should be its 
>> own cgroup.  From the hugetlb perspective absent any cgroups, things like 
>> hstates (since we're talking about HUGE_MAX_HSTATE) are global resources 
>> and so you'd need to preallocate these on the command line or via sysfs 
>> before you could mmap them.  So if my assumption that the hugetlb memcg 
>> controller is only governing these global resources and charging a set of 
>> tasks for what they use, then it really has no business in mm/memcontrol.c 
>> to begin with, in my opinion.
>

My first version was to do it as a seperate controller 

http://thread.gmane.org/gmane.linux.kernel.mm/73826

But the feedback I received was to do it as a part of memcg extension,
because what the controller is limiting is memory albeit a different
type. AFAIU there is also this goal of avoiding controller proliferation.

-aneesh

[PATCH] RDMA/ocrdma: Fix build with IPV6=n

[Roland Dreier]

From: Roland Dreier <roland@purestorage.com>

When IPV6 is not enabled:

    ERROR: "register_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!
    ERROR: "unregister_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!

Fix this by wrapping the inet6 calls in #ifdef IPV6.  Also make the
ocrdma module depend on (IPV6 || IPV6=n) to forbid the case of modular
ipv6 but built-in ocrdma (which can't work, because ocrdma calls ipv6
functions).

Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Roland Dreier <roland@purestorage.com>
---
OK, added this to my tree, should fix this.

Thanks,
  Roland

 drivers/infiniband/hw/ocrdma/Kconfig       |    2 +-
 drivers/infiniband/hw/ocrdma/ocrdma_main.c |   29 ++++++++++++++++++++--------
 2 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/infiniband/hw/ocrdma/Kconfig b/drivers/infiniband/hw/ocrdma/Kconfig
index cf99342..b5b6056 100644
--- a/drivers/infiniband/hw/ocrdma/Kconfig
+++ b/drivers/infiniband/hw/ocrdma/Kconfig
@@ -1,6 +1,6 @@
 config INFINIBAND_OCRDMA
 	tristate "Emulex One Connect HCA support"
-	depends on ETHERNET && NETDEVICES && PCI
+	depends on ETHERNET && NETDEVICES && PCI && (IPV6 || IPV6=n)
 	select NET_VENDOR_EMULEX
 	select BE2NET
 	---help---
diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_main.c b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
index 0bc1efb..a20d16e 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_main.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
@@ -51,12 +51,6 @@ static DEFINE_SPINLOCK(ocrdma_devlist_lock);
 static DEFINE_IDR(ocrdma_dev_id);
 
 static union ib_gid ocrdma_zero_sgid;
-static int ocrdma_inet6addr_event(struct notifier_block *,
-				  unsigned long, void *);
-
-static struct notifier_block ocrdma_inet6addr_notifier = {
-	.notifier_call = ocrdma_inet6addr_event
-};
 
 static int ocrdma_get_instance(void)
 {
@@ -204,6 +198,8 @@ static int ocrdma_build_sgid_tbl(struct ocrdma_dev *dev)
 	return 0;
 }
 
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+
 static int ocrdma_inet6addr_event(struct notifier_block *notifier,
 				  unsigned long event, void *ptr)
 {
@@ -259,6 +255,12 @@ static int ocrdma_inet6addr_event(struct notifier_block *notifier,
 	return NOTIFY_OK;
 }
 
+static struct notifier_block ocrdma_inet6addr_notifier = {
+	.notifier_call = ocrdma_inet6addr_event
+};
+
+#endif /* IPV6 */
+
 static enum rdma_link_layer ocrdma_link_layer(struct ib_device *device,
 					      u8 port_num)
 {
@@ -541,23 +543,34 @@ static struct ocrdma_driver ocrdma_drv = {
 	.state_change_handler	= ocrdma_event_handler,
 };
 
+static void ocrdma_unregister_inet6addr_notifier(void)
+{
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+	unregister_inet6addr_notifier(&ocrdma_inet6addr_notifier);
+#endif
+}
+
 static int __init ocrdma_init_module(void)
 {
 	int status;
 
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
 	status = register_inet6addr_notifier(&ocrdma_inet6addr_notifier);
 	if (status)
 		return status;
+#endif
+
 	status = be_roce_register_driver(&ocrdma_drv);
 	if (status)
-		unregister_inet6addr_notifier(&ocrdma_inet6addr_notifier);
+		ocrdma_unregister_inet6addr_notifier();
+
 	return status;
 }
 
 static void __exit ocrdma_exit_module(void)
 {
 	be_roce_unregister_driver(&ocrdma_drv);
-	unregister_inet6addr_notifier(&ocrdma_inet6addr_notifier);
+	ocrdma_unregister_inet6addr_notifier();
 }
 
 module_init(ocrdma_init_module);
-- 
1.7.9.5

Re: [PATCH] RDMA/ocrdma: Fix build with IPV6=n

[Randy Dunlap]

On 05/02/12 15:51, Roland Dreier wrote:

> From: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>
> 
> When IPV6 is not enabled:
> 
>     ERROR: "register_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!
>     ERROR: "unregister_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!
> 
> Fix this by wrapping the inet6 calls in #ifdef IPV6.  Also make the
> ocrdma module depend on (IPV6 || IPV6=n) to forbid the case of modular
> ipv6 but built-in ocrdma (which can't work, because ocrdma calls ipv6
> functions).
> 
> Reported-by: Randy Dunlap <rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>
> Signed-off-by: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>


Acked-by: Randy Dunlap <rdunlap-/UHa2rfvQTnk1uMJSBkQmQ@public.gmane.org>

Thanks.

> ---
> OK, added this to my tree, should fix this.
> 
> Thanks,
>   Roland
> 
>  drivers/infiniband/hw/ocrdma/Kconfig       |    2 +-
>  drivers/infiniband/hw/ocrdma/ocrdma_main.c |   29 ++++++++++++++++++++--------
>  2 files changed, 22 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/ocrdma/Kconfig b/drivers/infiniband/hw/ocrdma/Kconfig
> index cf99342..b5b6056 100644
> --- a/drivers/infiniband/hw/ocrdma/Kconfig
> +++ b/drivers/infiniband/hw/ocrdma/Kconfig
> @@ -1,6 +1,6 @@
>  config INFINIBAND_OCRDMA
>  	tristate "Emulex One Connect HCA support"
> -	depends on ETHERNET && NETDEVICES && PCI
> +	depends on ETHERNET && NETDEVICES && PCI && (IPV6 || IPV6=n)
>  	select NET_VENDOR_EMULEX
>  	select BE2NET
>  	---help---
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_main.c b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> index 0bc1efb..a20d16e 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> @@ -51,12 +51,6 @@ static DEFINE_SPINLOCK(ocrdma_devlist_lock);
>  static DEFINE_IDR(ocrdma_dev_id);
>  
>  static union ib_gid ocrdma_zero_sgid;
> -static int ocrdma_inet6addr_event(struct notifier_block *,
> -				  unsigned long, void *);
> -
> -static struct notifier_block ocrdma_inet6addr_notifier = {
> -	.notifier_call = ocrdma_inet6addr_event
> -};
>  
>  static int ocrdma_get_instance(void)
>  {
> @@ -204,6 +198,8 @@ static int ocrdma_build_sgid_tbl(struct ocrdma_dev *dev)
>  	return 0;
>  }
>  
> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> +
>  static int ocrdma_inet6addr_event(struct notifier_block *notifier,
>  				  unsigned long event, void *ptr)
>  {
> @@ -259,6 +255,12 @@ static int ocrdma_inet6addr_event(struct notifier_block *notifier,
>  	return NOTIFY_OK;
>  }
>  
> +static struct notifier_block ocrdma_inet6addr_notifier = {
> +	.notifier_call = ocrdma_inet6addr_event
> +};
> +
> +#endif /* IPV6 */
> +
>  static enum rdma_link_layer ocrdma_link_layer(struct ib_device *device,
>  					      u8 port_num)
>  {
> @@ -541,23 +543,34 @@ static struct ocrdma_driver ocrdma_drv = {
>  	.state_change_handler	= ocrdma_event_handler,
>  };
>  
> +static void ocrdma_unregister_inet6addr_notifier(void)
> +{
> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> +	unregister_inet6addr_notifier(&ocrdma_inet6addr_notifier);
> +#endif
> +}
> +
>  static int __init ocrdma_init_module(void)
>  {
>  	int status;
>  
> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
>  	status = register_inet6addr_notifier(&ocrdma_inet6addr_notifier);
>  	if (status)
>  		return status;
> +#endif
> +
>  	status = be_roce_register_driver(&ocrdma_drv);
>  	if (status)
> -		unregister_inet6addr_notifier(&ocrdma_inet6addr_notifier);
> +		ocrdma_unregister_inet6addr_notifier();
> +
>  	return status;
>  }
>  
>  static void __exit ocrdma_exit_module(void)
>  {
>  	be_roce_unregister_driver(&ocrdma_drv);
> -	unregister_inet6addr_notifier(&ocrdma_inet6addr_notifier);
> +	ocrdma_unregister_inet6addr_notifier();
>  }
>  
>  module_init(ocrdma_init_module);



-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] RDMA/ocrdma: Fix build with IPV6=n

[Randy Dunlap]

On 05/02/12 15:51, Roland Dreier wrote:

> From: Roland Dreier <roland@purestorage.com>
> 
> When IPV6 is not enabled:
> 
>     ERROR: "register_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!
>     ERROR: "unregister_inet6addr_notifier" [drivers/infiniband/hw/ocrdma/ocrdma.ko] undefined!
> 
> Fix this by wrapping the inet6 calls in #ifdef IPV6.  Also make the
> ocrdma module depend on (IPV6 || IPV6=n) to forbid the case of modular
> ipv6 but built-in ocrdma (which can't work, because ocrdma calls ipv6
> functions).
> 
> Reported-by: Randy Dunlap <rdunlap@xenotime.net>
> Signed-off-by: Roland Dreier <roland@purestorage.com>


Acked-by: Randy Dunlap <rdunlap@xenotime.net>

Thanks.

> ---
> OK, added this to my tree, should fix this.
> 
> Thanks,
>   Roland
> 
>  drivers/infiniband/hw/ocrdma/Kconfig       |    2 +-
>  drivers/infiniband/hw/ocrdma/ocrdma_main.c |   29 ++++++++++++++++++++--------
>  2 files changed, 22 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/ocrdma/Kconfig b/drivers/infiniband/hw/ocrdma/Kconfig
> index cf99342..b5b6056 100644
> --- a/drivers/infiniband/hw/ocrdma/Kconfig
> +++ b/drivers/infiniband/hw/ocrdma/Kconfig
> @@ -1,6 +1,6 @@
>  config INFINIBAND_OCRDMA
>  	tristate "Emulex One Connect HCA support"
> -	depends on ETHERNET && NETDEVICES && PCI
> +	depends on ETHERNET && NETDEVICES && PCI && (IPV6 || IPV6=n)
>  	select NET_VENDOR_EMULEX
>  	select BE2NET
>  	---help---
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_main.c b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> index 0bc1efb..a20d16e 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
> @@ -51,12 +51,6 @@ static DEFINE_SPINLOCK(ocrdma_devlist_lock);
>  static DEFINE_IDR(ocrdma_dev_id);
>  
>  static union ib_gid ocrdma_zero_sgid;
> -static int ocrdma_inet6addr_event(struct notifier_block *,
> -				  unsigned long, void *);
> -
> -static struct notifier_block ocrdma_inet6addr_notifier = {
> -	.notifier_call = ocrdma_inet6addr_event
> -};
>  
>  static int ocrdma_get_instance(void)
>  {
> @@ -204,6 +198,8 @@ static int ocrdma_build_sgid_tbl(struct ocrdma_dev *dev)
>  	return 0;
>  }
>  
> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> +
>  static int ocrdma_inet6addr_event(struct notifier_block *notifier,
>  				  unsigned long event, void *ptr)
>  {
> @@ -259,6 +255,12 @@ static int ocrdma_inet6addr_event(struct notifier_block *notifier,
>  	return NOTIFY_OK;
>  }
>  
> +static struct notifier_block ocrdma_inet6addr_notifier = {
> +	.notifier_call = ocrdma_inet6addr_event
> +};
> +
> +#endif /* IPV6 */
> +
>  static enum rdma_link_layer ocrdma_link_layer(struct ib_device *device,
>  					      u8 port_num)
>  {
> @@ -541,23 +543,34 @@ static struct ocrdma_driver ocrdma_drv = {
>  	.state_change_handler	= ocrdma_event_handler,
>  };
>  
> +static void ocrdma_unregister_inet6addr_notifier(void)
> +{
> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> +	unregister_inet6addr_notifier(&ocrdma_inet6addr_notifier);
> +#endif
> +}
> +
>  static int __init ocrdma_init_module(void)
>  {
>  	int status;
>  
> +#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
>  	status = register_inet6addr_notifier(&ocrdma_inet6addr_notifier);
>  	if (status)
>  		return status;
> +#endif
> +
>  	status = be_roce_register_driver(&ocrdma_drv);
>  	if (status)
> -		unregister_inet6addr_notifier(&ocrdma_inet6addr_notifier);
> +		ocrdma_unregister_inet6addr_notifier();
> +
>  	return status;
>  }
>  
>  static void __exit ocrdma_exit_module(void)
>  {
>  	be_roce_unregister_driver(&ocrdma_drv);
> -	unregister_inet6addr_notifier(&ocrdma_inet6addr_notifier);
> +	ocrdma_unregister_inet6addr_notifier();
>  }
>  
>  module_init(ocrdma_init_module);



-- 
~Randy

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[David Rientjes]

On Sat, 28 Apr 2012, Aneesh Kumar K.V wrote:

> My first version was to do it as a seperate controller 
> 
> http://thread.gmane.org/gmane.linux.kernel.mm/73826
> 
> But the feedback I received was to do it as a part of memcg extension,
> because what the controller is limiting is memory albeit a different
> type. AFAIU there is also this goal of avoiding controller proliferation.
> 

Maybe Kame can speak up if he feels strongly about this, but I really 
think it should be its own controller in its own file (which would 
obviously make this discussion irrelevant since mm/hugetlbcg.c would be 
dependent on your own config symbol).  I don't feel like this is the same 
as kmem since its not a global resource like hugetlb pages are.

Hugetlb pages can either be allocated statically on the command line at 
boot or dynamically via sysfs and they are globally available to whoever 
mmaps them through hugetlbfs.  I see a real benefit from being able to 
limit the number of hugepages in the global pool to a set of tasks so they 
can't overuse what has been statically or dynamically allocated.  And that 
ability should be available, in my opinion, without having to enable 
memcg, the page_cgroup metadata overhead that comes along with it, and the 
performance impact in using it.  I also think it would be wise to seperate 
it out into its own file at the source level so things like this don't 
arise in the future.

What do you think?  Kame?

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Hiroyuki Kamezawa]

On Thu, May 3, 2012 at 6:13 PM, David Rientjes <rientjes@google.com> wrote:
> On Sat, 28 Apr 2012, Aneesh Kumar K.V wrote:
>
>> My first version was to do it as a seperate controller
>>
>> http://thread.gmane.org/gmane.linux.kernel.mm/73826
>>
>> But the feedback I received was to do it as a part of memcg extension,
>> because what the controller is limiting is memory albeit a different
>> type. AFAIU there is also this goal of avoiding controller proliferation.
>>
>
> Maybe Kame can speak up if he feels strongly about this, but I really
> think it should be its own controller in its own file (which would
> obviously make this discussion irrelevant since mm/hugetlbcg.c would be
> dependent on your own config symbol).  I don't feel like this is the same
> as kmem since its not a global resource like hugetlb pages are.
>
> Hugetlb pages can either be allocated statically on the command line at
> boot or dynamically via sysfs and they are globally available to whoever
> mmaps them through hugetlbfs.  I see a real benefit from being able to
> limit the number of hugepages in the global pool to a set of tasks so they
> can't overuse what has been statically or dynamically allocated.  And that
> ability should be available, in my opinion, without having to enable
> memcg, the page_cgroup metadata overhead that comes along with it, and the
> performance impact in using it.  I also think it would be wise to seperate
> it out into its own file at the source level so things like this don't
> arise in the future.
>
> What do you think?  Kame?

I think hugetlb should be handled under memcg.

1. I think Hugetlb is memory.

2. The characteristics of hugetlb usage you pointed out is
characteristics comes from
   "current" implementation.
    Yes, it's now unreclaimable and should be allocated by hands of
admin. But,
    considering recent improvements, memory-defrag, CMA, it can be less
    hard-to-use thing by updating implementation and on-demand allocation
    can be allowed.

3. If overhead is the problem, and it's better to disable memcg,
    Please show numbers with HPC apps. I didn't think memcg has very
bad overhead
    with Bull's presentation in collaboration summit, this April.

4. I guess a user who uses hugetlbfs will use usual memory at the same time.
    Having 2 hierarchy for memory and hugetlb will bring him a confusion.

Thanks,
-Kame

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Aneesh Kumar K.V]

David Rientjes <rientjes@google.com> writes:

>> My first version was to do it as a seperate controller 
>> 
>> http://thread.gmane.org/gmane.linux.kernel.mm/73826
>> 
>> But the feedback I received was to do it as a part of memcg extension,
>> because what the controller is limiting is memory albeit a different
>> type. AFAIU there is also this goal of avoiding controller proliferation.
>> 
>
> Maybe Kame can speak up if he feels strongly about this, but I really 
> think it should be its own controller in its own file (which would 
> obviously make this discussion irrelevant since mm/hugetlbcg.c would be 
> dependent on your own config symbol).  I don't feel like this is the same 
> as kmem since its not a global resource like hugetlb pages are.

> Hugetlb pages can either be allocated statically on the command line at 
> boot or dynamically via sysfs and they are globally available to whoever 
> mmaps them through hugetlbfs.  I see a real benefit from being able to 
> limit the number of hugepages in the global pool to a set of tasks so they 
> can't overuse what has been statically or dynamically allocated.  And that 
> ability should be available, in my opinion, without having to enable 
> memcg, the page_cgroup metadata overhead that comes along with it, and the 
> performance impact in using it.  I also think it would be wise to seperate 
> it out into its own file at the source level so things like this don't 
> arise in the future.

All the use cases I came across requested for limiting both memory
and hugetlb pages. They want to limit the usage of both. So for the use case
I am looking at memcg will already be enabled.

-aneesh

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[David Rientjes]

On Thu, 3 May 2012, Aneesh Kumar K.V wrote:

> All the use cases I came across requested for limiting both memory
> and hugetlb pages. They want to limit the usage of both.

And as cgroups moves to a single hierarchy for simplification, this isn't 
hard to do by mounting both cgroups.

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[David Rientjes]

On Thu, 3 May 2012, Hiroyuki Kamezawa wrote:

> I think hugetlb should be handled under memcg.
> 
> 1. I think Hugetlb is memory.
> 

Agreed, but hugetlb control is done in a very different way than regular 
memory in terms of implementation and preallocation.  Just because it's 
called "memory controller" doesn't mean it must control all types of 
memory; hugetlb has always been considered a seperate type of VM that 
diverges quite radically from the VM implementation.  Forcing users into 
an all-or-nothing approach is a lousy solution when its simpler, cleaner, 
more extendable, and doesn't lose any functionality when seperated.

> 2. The characteristics of hugetlb usage you pointed out is
> characteristics comes from
>    "current" implementation.
>     Yes, it's now unreclaimable and should be allocated by hands of
> admin. But,
>     considering recent improvements, memory-defrag, CMA, it can be less
>     hard-to-use thing by updating implementation and on-demand allocation
>     can be allowed.
> 

You're describing transparent hugepages which are already supported by 
memcg specifically because they are transparent.  I haven't seen any 
proposals on how to change hugetlb when it comes to preallocation and 
mmaping the memory because it would break the API with userspace.  
Userspace packages like hugeadm are actually used in a wide variety of 
places.

 [ I would love to see hugetlb be deprecated entirely and move in a 
   direction where transparent hugepages can make that happen, but we're 
   not there yet because we're missing key functionality such as pagecache 
   support. ]

> 3. If overhead is the problem, and it's better to disable memcg,
>     Please show numbers with HPC apps. I didn't think memcg has very
> bad overhead
>     with Bull's presentation in collaboration summit, this April.
> 

Is this a claim that memory-intensive workloads will have the exact same 
performance with and without memcg enabled?  That would be quite an 
amazing feat, I agree, since tracking user pages would have absolutely 
zero cost.  Please clarify your answer here and whether memcg is not 
expected to cause even the slightest performance degradation on any 
workload, I want to make sure I'm understanding it correctly.  I'll follow 
up after that.

Even if there's the slightest performance degradation, these are what 
users of hugetlb are concerned with already.  They use hugetlb for 
performance and it would be a shame for it to regress because you have to 
enable memcg.

> 4. I guess a user who uses hugetlbfs will use usual memory at the same time.
>     Having 2 hierarchy for memory and hugetlb will bring him a confusion.
> 

Cgroups is moving to a single hierarchy for simplification, this isn't the 
only example of where this is currently suboptimal and it would be 
disappointing to solidify hugetlb control as part of memcg because of this 
current limitation that will be addressed by generic cgroups development.

Folks, once these things are merged they become an API that can't easily 
be shifted around and seperated out later.  The decision now is either to 
join hugetlb control with memcg forever when they act in very different 
ways or to seperate them so they can be used and configured individually.

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[David Rientjes]

On Thu, 3 May 2012, David Rientjes wrote:

> Is this a claim that memory-intensive workloads will have the exact same 
> performance with and without memcg enabled?

I've just run specjbb2005 three times on my system both with and without 
cgroup_disable=memory on the command line and it is consistently 1% faster 
without memcg.  If I add XX:+UseLargePages to the command line to use 
hugepages it's even larger.  So why must I incur this performance 
degradation if I simply want to control who may mmap hugepages out of the 
global pool?

The functionality to control this is pretty important if I want to ensure 
applications aren't able to infringe on the preallocated hugepages of a 
higher priority application for business goals.

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Hiroyuki Kamezawa]

On Fri, May 4, 2012 at 5:56 AM, David Rientjes <rientjes@google.com> wrote:
> On Thu, 3 May 2012, Hiroyuki Kamezawa wrote:
>
>> I think hugetlb should be handled under memcg.

>> 2. The characteristics of hugetlb usage you pointed out is
>> characteristics comes from
>>    "current" implementation.
>>     Yes, it's now unreclaimable and should be allocated by hands of
>> admin. But,
>>     considering recent improvements, memory-defrag, CMA, it can be less
>>     hard-to-use thing by updating implementation and on-demand allocation
>>     can be allowed.
>>
>
> You're describing transparent hugepages which are already supported by
> memcg specifically because they are transparent.

THP just handles hugepages whose size is equal to pgd size. So, hugetlb
is something more than that, it has various sizes.

> I haven't seen any
> proposals on how to change hugetlb when it comes to preallocation and
> mmaping the memory because it would break the API with userspace.
> Userspace packages like hugeadm are actually used in a wide variety of
> places.
>

I just said if users doesn't need to set sysctl, it's more useful. I got similar
claims from users with IPC max params ;) I answerd set it unlimited...


>> 3. If overhead is the problem, and it's better to disable memcg,
>>     Please show numbers with HPC apps. I didn't think memcg has very
>> bad overhead
>>     with Bull's presentation in collaboration summit, this April.
>>
>
> Is this a claim that memory-intensive workloads will have the exact same
> performance with and without memcg enabled?

I wrote that I don't get any report that memcg is too slow and need to be fixed.

I think, in general, once memory is allocated, application will run
faster if it never
free memory. So, good application frees memory in batch when it can do. Because
memcg just adds overheads to memory allocation and unmapping, runtime overhead
tend to be small.
My target number when I started to join memcg developments was 2-3% overheads.

> Even if there's the slightest performance degradation, these are what
> users of hugetlb are concerned with already.  They use hugetlb for
> performance and it would be a shame for it to regress because you have to
> enable memcg.
>

I think such people don't limit any usages....any kinds of
virtualization/resource controls has 0 overheads.

>> 4. I guess a user who uses hugetlbfs will use usual memory at the same time.
>>     Having 2 hierarchy for memory and hugetlb will bring him a confusion.
>>
>
> Cgroups is moving to a single hierarchy for simplification, this isn't the
> only example of where this is currently suboptimal and it would be
> disappointing to solidify hugetlb control as part of memcg because of this
> current limitation that will be addressed by generic cgroups development.
>
> Folks, once these things are merged they become an API that can't easily
> be shifted around and seperated out later.  The decision now is either to
> join hugetlb control with memcg forever when they act in very different
> ways or to seperate them so they can be used and configured individually.

How do other guys think ? Tejun ?

Thanks,
-Kame

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Hiroyuki Kamezawa]

On Fri, May 4, 2012 at 6:57 AM, David Rientjes <rientjes@google.com> wrote:
> On Thu, 3 May 2012, David Rientjes wrote:
>
>> Is this a claim that memory-intensive workloads will have the exact same
>> performance with and without memcg enabled?
>
> I've just run specjbb2005 three times on my system both with and without
> cgroup_disable=memory on the command line and it is consistently 1% faster
> without memcg.
Hm, ok. Where is that overheads from ? Do you have perf output ?
I'll need to check what is bad.

> If I add XX:+UseLargePages to the command line to use
> hugepages it's even larger.  So why must I incur this performance
> degradation if I simply want to control who may mmap hugepages out of the
> global pool?

Is that common use case ? If he wants to do some resource control,
common users will limit usual memory, too. That kinds of too much flexibility
makes cgroup complicated, hard-to-use.

Thanks,
-Kame

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Hiroyuki Kamezawa]

On Fri, May 4, 2012 at 8:21 AM, Hiroyuki Kamezawa
<kamezawa.hiroyuki@gmail.com> wrote:
> On Fri, May 4, 2012 at 6:57 AM, David Rientjes <rientjes@google.com> wrote:
>> On Thu, 3 May 2012, David Rientjes wrote:
>> If I add XX:+UseLargePages to the command line to use
>> hugepages it's even larger.

Ah, sorry. I couldn't understand this. Why performance difference gets larger if
usage of anon memory decreases ? I guess overheads are just added to anon page
faults and file cache handling. If you use Hugepage, anon memory overheads will
disappear.

Thanks,
-Kame

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Tejun Heo]

Hello,

(cc'ing Johannes and Michal, hi guys)

On Fri, May 04, 2012 at 08:17:11AM +0900, Hiroyuki Kamezawa wrote:
> > Cgroups is moving to a single hierarchy for simplification, this isn't the
> > only example of where this is currently suboptimal and it would be
> > disappointing to solidify hugetlb control as part of memcg because of this
> > current limitation that will be addressed by generic cgroups development.
> >
> > Folks, once these things are merged they become an API that can't easily
> > be shifted around and seperated out later.  The decision now is either to
> > join hugetlb control with memcg forever when they act in very different
> > ways or to seperate them so they can be used and configured individually.
> 
> How do other guys think ? Tejun ?

I don't know.  hugetlbfs already is this franken thing which is
separate from the usual memory management.  It needing cgroup type
resource limitation feels a bit weird to me.  Isn't this supposed to
be used in more-or-less tightly controlled setups?  The whole thing
needs to have its memory cut out from boot after all.

If someone really has to add cgroup support to hugetlbfs, I'm more
inclined to say let them play in their own corner unless incorporating
it into memcg makes it inherently better.

That said, I really don't know that much about mm.  Johannes, Michal,
what do you guys think?

Thanks.

-- 
tejun

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Aneesh Kumar K.V]

David Rientjes <rientjes@google.com> writes:

>> Is this a claim that memory-intensive workloads will have the exact same 
>> performance with and without memcg enabled?

> I've just run specjbb2005 three times on my system both with and without 
> cgroup_disable=memory on the command line and it is consistently 1% faster 
> without memcg.  If I add XX:+UseLargePages to the command line to use 
> hugepages it's even larger.  So why must I incur this performance 
> degradation if I simply want to control who may mmap hugepages out of the 
> global pool?

Even if we end up having a seperate controller for hugetlb, we would need
some bits of memcg, like tracking page cgroup, moving page cgroup on
page offline. We will also be duplicating some amount of framework for
supporting cgroup removal etc, because all those code deal with struct
page (actually compound page )

-aneesh

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Michal Hocko]

On Fri 04-05-12 10:24:20, Tejun Heo wrote:
> Hello,
> 
> (cc'ing Johannes and Michal, hi guys)
> 
> On Fri, May 04, 2012 at 08:17:11AM +0900, Hiroyuki Kamezawa wrote:
> > > Cgroups is moving to a single hierarchy for simplification, this isn't the
> > > only example of where this is currently suboptimal and it would be
> > > disappointing to solidify hugetlb control as part of memcg because of this
> > > current limitation that will be addressed by generic cgroups development.
> > >
> > > Folks, once these things are merged they become an API that can't easily
> > > be shifted around and seperated out later.  The decision now is either to
> > > join hugetlb control with memcg forever when they act in very different
> > > ways or to seperate them so they can be used and configured individually.
> > 
> > How do other guys think ? Tejun ?
> 
> I don't know.  hugetlbfs already is this franken thing which is
> separate from the usual memory management.  It needing cgroup type
> resource limitation feels a bit weird to me.  Isn't this supposed to
> be used in more-or-less tightly controlled setups?  The whole thing
> needs to have its memory cut out from boot after all.
> 
> If someone really has to add cgroup support to hugetlbfs, I'm more
> inclined to say let them play in their own corner unless incorporating
> it into memcg makes it inherently better.

I would agree with you but my impression from the previous (hugetlb)
implementation was that it is much harder to implement the charge moving
if we do not use page_cgroup.
Also the range tracking is rather ugly and clumsy.

> That said, I really don't know that much about mm.  Johannes, Michal,
> what do you guys think?
> 
> Thanks.
> 
> -- 
> tejun

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Tejun Heo]

Hello,

On Mon, May 07, 2012 at 04:01:04PM +0200, Michal Hocko wrote:
> > If someone really has to add cgroup support to hugetlbfs, I'm more
> > inclined to say let them play in their own corner unless incorporating
> > it into memcg makes it inherently better.
> 
> I would agree with you but my impression from the previous (hugetlb)
> implementation was that it is much harder to implement the charge moving
> if we do not use page_cgroup.
> Also the range tracking is rather ugly and clumsy.

Understood.  I haven't looked at the code, so my opinion was based on
the assumption that the whole thing is completely separate (in design
and implementation) from memcg as hugtlbfs is from the usual mm.  If
it's better / easier implemented together with memcg, I have no
objection to making it part of memcg.

Thanks.

-- 
tejun

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

[Michal Hocko]

On Mon 07-05-12 10:08:40, Tejun Heo wrote:
> Hello,
> 
> On Mon, May 07, 2012 at 04:01:04PM +0200, Michal Hocko wrote:
> > > If someone really has to add cgroup support to hugetlbfs, I'm more
> > > inclined to say let them play in their own corner unless incorporating
> > > it into memcg makes it inherently better.
> > 
> > I would agree with you but my impression from the previous (hugetlb)
> > implementation was that it is much harder to implement the charge moving
> > if we do not use page_cgroup.
> > Also the range tracking is rather ugly and clumsy.
> 
> Understood.  I haven't looked at the code, so my opinion was based on
> the assumption that the whole thing is completely separate (in design
> and implementation) from memcg as hugtlbfs is from the usual mm.  If
> it's better / easier implemented together with memcg, I have no
> objection to making it part of memcg.

I think we could still consider a possibility of using page_cgroup for
tracking without the rest of memcg infrastructure (charging) in place.
It sounds like the memory overhead would be too big (at least now) for
relatively few hugetlb pages in use but it would reduce the performance
hit if a user is interested only in the hugetlb limits (mentioned by
David in the other email).
On the other hand we are on the way to get rid of page_cgroup and push
the missing parts into the struct page. Then we could accomplish the
hugetlb only use case by cgroup_disable=memory hugetlbaccount=1 kernel
parameters (yes still not very nice...).
That being said I think that going memcg way is simpler and that the
!memcg && hugetlb use case is still possible (somehow).

Or does anybody have a different idea?
-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic