2.6.19-rc1-mm1
in [Kernel]
|
Prev: irq issues ("nobody cared")
Next: Hugepage regression
From: Andrew Morton on 10 Oct 2006 03:20 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/ - Added the ext4 filesystem. Quick usage instructions: - Grab updated e2fsprogs from ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs-interim/ - It's still mke2fs -j /dev/hda1 - mount /dev/hda1 /wherever -t ext4dev - To enable extents, mount /dev/hda1 /wherever -t ext4dev -o extents - The filesystem is compatible with the ext3 driver until you add a file which has extents (ie: `mount -o extents', then create a file). - When comparing performance with other filesystems, remember that ext3/4 by default offers higher data integrity guarantees than most. So when comparing with a metadata-only journalling filesystem, use `mount -o data=writeback'. (Although this doesn't seem to make much difference with ext3). And you might as well use `mount -o nobh' too. Making the journal larger than the mke2fs default often helps performance with metadata-intensive workloads. - Added the high-resolution timers and dynamic-ticks code. Please be sure to cc tglx(a)linutronix.de>, mingo(a)elte.hu and johnstul(a)us.ibm.com if it blows up. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail majordomo(a)vger.kernel.org - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Semi-daily snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. Changes since 2.6.18-mm3: origin.patch git-acpi.patch git-cifs.patch git-dvb.patch git-geode.patch git-ia64.patch git-ieee1394.patch git-infiniband.patch git-libata-all.patch git-mtd.patch git-netdev-all.patch git-ocfs2.patch git-pcmcia.patch git-selinux.patch git-pciseg.patch git-s390.patch git-sh.patch git-scsi-target.patch git-qla3xxx.patch git-watchdog.patch git-gccbug.patch git trees. -pidh-cleanup.patch -vfs-make-filldir_t-and-struct-kstat-deal-in-64-bit-inode-numbers.patch -revert-insert-ioapics-and-local-apic-into-resource-map.patch -acpi-cast-removal.patch -dereference-after-free-in-snd_hwdep_release.patch -kauditd_thread-warning-fix.patch -hdrcheck-permission-fix.patch -docs-small-kbuild-cleanup.patch -kthread-update-arch-mips-kernel-apmc.patch -mmc-driver-for-ti-flashmedia-card-reader-source.patch -mmc-driver-for-ti-flashmedia-card-reader-kconfig-makefile.patch -forcedeth-hardirq-lockdep-warning.patch -hp100-fix-conditional-compilation-mess.patch -zatm-always-clear-pcr-in-alloc_shaper.patch -atm-ambassador-fix-return-code-bug.patch -tipc-fix-printk-warning.patch -git-powerpc-wrapper-dont-require-execute-permissions.patch -powerpc-xmon-fix.patch -pcie_portdrv_restore_config-undefined-without-config_pm.patch -pci-optionally-sort-device-lists-breadth-first.patch -scsi-convertion-to-struct-scsi_cmnd-in-ips-driver.patch -scsi-scsi_cmnd-convertion-in-arm-subtree.patch -gregkh-usb-usb-storage-unusual_devs.h-entry-for-sony-ericsson-p990i.patch -usb-serial-mos7840-fix-cast.patch -x86_64-mm-defconfig-update.patch -x86_64-mm-i386-defconfig-update.patch -x86_64-mm-calgary-init.patch -x86_64-mm-calgary-off-by-one.patch -x86_64-mm-calgary-jon-contact.patch -x86_64-mm-calgary-hex-bus.patch -x86_64-mm-pci-bios-fix.patch -x86_64-mm-kernel-stack-termination.patch -fix-x86_64-mm-kernel-stack-termination.patch -mm-micro-optimise-zone_watermark_ok.patch -slab-clean-up-leak-tracking-ifdefs-a-little-bit.patch -kmemdup-introduce-vs-slab-clean-up-leak-tracking-ifdefs-a-little-bit.patch -slab-reduce-numa-text-size.patch -slab-reduce-numa-text-size-tidy.patch -create-kallsyms_lookup_size_offset.patch -low-performance-of-lib-sortc.patch -char-kill-unneeded-memsets.patch -char-serial167-remove-useless-tty-check.patch -kernel-doc-for-kernel-dmac.patch -kernel-doc-for-kernel-resourcec.patch -fs-eventpoll-error-handling-micro-cleanup.patch -ipmi-fix-uninitd-data-bug.patch -drivers-char-ip2-kill-unused-code-label.patch -schedule-ftape-removal.patch -isdn-warning-fixes.patch -restore-parport_pc-probing-on-powermac.patch -add-pekka-to-credits.patch -ipmi-allow-user-to-override-the-kernel-ipmi-daemon-enable.patch -ipmi-allow-user-to-override-the-kernel-ipmi-daemon-enable-tidy.patch -ia64-note-requirement-for-8250_pnp-now-that-8250_acpi-is-gone.patch -maintainers-removes-duplicated-entry.patch -pktcdvd-replace-pktcdvd-strings-with-macro-driver_name.patch -pktcdvd-rename-a-variable-for-better-readability.patch -remove-unnecessary-check-in-fs-reiserfs-inodec.patch -add-unifdef-to-gitignore.patch -fix-spurious-error-on-tags-target-when-missing-defconfig.patch -pata_hpt366-fix-typo.patch -hisax-niccy-cleanup.patch -knfsd-nfsd-lockdep-annotation-fix.patch -knfsd-call-lockd_down-when-closing-a-socket-via-a-write-to-nfsd-portlist.patch -knfsd-protect-update-to-sn_nrthreads-with-lock_kernel.patch -knfsd-fixed-handling-of-lockd-fail-when-adding-nfsd-socket.patch -knfsd-replace-two-page-lists-in-struct-svc_rqst-with-one.patch -knfsd-replace-two-page-lists-in-struct-svc_rqst-with-one-fix.patch -knfsd-avoid-excess-stack-usage-in-svc_tcp_recvfrom.patch -knfsd-prepare-knfsd-for-support-of-rsize-wsize-of-up-to-1mb-over-tcp.patch -knfsd-allow-max-size-of-nfsd-payload-to-be-configured.patch -
From: Arjan van de Ven on 10 Oct 2006 03:30 On Tue, 2006-10-10 at 00:09 -0700, Andrew Morton wrote: > +htlb-forget-rss-with-pt-sharing.patch if it's ok to ignore RSS, can we consider the shared pagetables for normal pages patch? It saves quite a bit of memory on even desktop workloads as well as avoiding several (soft) pagefaults. So.. what does RSS actually mean? Can we ignore it somewhat for shared-readonly mappings ? -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Miguel Ojeda on 10 Oct 2006 03:40 On 10/10/06, Andrew Morton <akpm(a)osdl.org> wrote: > > +# drivers-add-lcd-support.patch: Pavel says use fbcon > +drivers-add-lcd-support.patch > +drivers-add-lcd-support-update.patch > Has the # a special meaning? I'm going to work on offering the fbcon feature as Pavel requested. We suggested 2 ways. Pavel's idea: Change the driver so the cfag12864b module will be just a framebuffer device, removing access through /dev/cfag12864b. My idea: Code a new module called "fbcfag12864b", which will depend on cfag12864b and will be the framebuffer device. This way we have both devices, and they doesn't affect each other as they are different things. So the ks0108 and cfag12864b can stay without any changes. Also, if we finally decide we don't want the raw cfag12864b module, it is easy to remove it from the cfag12864b and the fbcafg12864b will continue working. Is there anyone who can decide which idea is better? If not, I will code it my way. Also, if the Pavel's idea will be the chosen one, it will be easier to put the fbcfag12864b code into the cfag12864b rather than the opposite. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 10 Oct 2006 03:50 On Tue, 10 Oct 2006 09:20:00 +0200 Arjan van de Ven <arjan(a)infradead.org> wrote: > On Tue, 2006-10-10 at 00:09 -0700, Andrew Morton wrote: > > +htlb-forget-rss-with-pt-sharing.patch Which I didn't write. cc's added. > if it's ok to ignore RSS, We'd prefer not to. But what's the alternative? > can we consider the shared pagetables for > normal pages patch? Has been repeatedly considered, but Hugh keeps finding bugs in it. > It saves quite a bit of memory on even desktop > workloads as well as avoiding several (soft) pagefaults. > > So.. what does RSS actually mean? Can we ignore it somewhat for > shared-readonly mappings ? We'd prefer to go the other way, and implement RLIMIT_RSS wouldn't we? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 10 Oct 2006 04:20
On Tue, 10 Oct 2006 07:31:23 +0000 "Miguel Ojeda" <maxextreme(a)gmail.com> wrote: > On 10/10/06, Andrew Morton <akpm(a)osdl.org> wrote: > > > > +# drivers-add-lcd-support.patch: Pavel says use fbcon > > +drivers-add-lcd-support.patch > > +drivers-add-lcd-support-update.patch > > > > Has the # a special meaning? It's a comment separator ;) > I'm going to work on offering the fbcon feature as Pavel requested. Thanks. It does sound like making the thing an fbdev is the right way to go. > suggested 2 ways. > > Pavel's idea: Change the driver so the cfag12864b module will be just > a framebuffer device, removing access through /dev/cfag12864b. > > My idea: Code a new module called "fbcfag12864b", which will depend on > cfag12864b and will be the framebuffer device. This way we have both > devices, and they doesn't affect each other as they are different > things. So the ks0108 and cfag12864b can stay without any changes. > Also, if we finally decide we don't want the raw cfag12864b module, it > is easy to remove it from the cfag12864b and the fbcafg12864b will > continue working. > > Is there anyone who can decide which idea is better? If not, I will > code it my way. Also, if the Pavel's idea will be the chosen one, it > will be easier to put the fbcfag12864b code into the cfag12864b rather > than the opposite. I'd have thought that once the device is accessible as an fbdev, there's so much other software and kernel infrastructure to support that, there's little point in offering an alternative way of presenting the device to userspace. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |