Message-Id: <20071001233225.88c67e8b.akpm@linux-foundation.org>
Date:	Mon, 1 Oct 2007 23:32:25 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org, mpm@...enic.com,
	"Huang, Ying" <ying.huang@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Christoph Lameter <clameter@....com>
Subject: Re: x86 patches was Re: -mm merge plans for 2.6.24

On 02 Oct 2007 08:18:17 +0200 Andi Kleen <andi@...stfloor.org> wrote:

> Andrew Morton <akpm@...ux-foundation.org> writes:
> > 
> > revert-x86_64-mm-cpa-einval.patch
> > fix-x86_64-mm-sched-clock-share.patch
> > agp-fix-race-condition-between-unmapping-and-freeing-pages.patch
> > x86_64-mce-poll-at-idle_start-and-printk-fix.patch
> > fix-x86_64-mm-unwinder.patch
> > geode-mfgpt-support-for-geode-class-machines.patch
> > geode-mfgpt-clock-event-device-support.patch
> > x86_64-add-acpi-reboot-option.patch
> > i386-convert-mm_context_t-semaphore-to-a-mutex.patch
> > dma-use-dev_to_node-to-get-node-for-device-in-dma_alloc_pages.patch
> > x86-make-io-apic-not-connected-pin-print-complete.patch
> > intel_cacheinfo-misc-section-annotation-fixes.patch
> > intel_cacheinfo-call-cache_add_dev-from-cache_sysfs_init.patch
> > x86-use-num_online_nodes-to-get-physical-cpus-numbers-for.patch
> > i386-stop-bogus-nmi-softlockup-warnings-in-show_mem.patch
> > voyager-include-asm-smph-to-fix-compile-error.patch
> > x86-64-disable-local-apic-timer-use-on-amd-systems-with-c1e.patch
> > clockevents-remove-unused-inline-function.patch
> > clockevents-allow-build-without-runtime-use.patch
> > x86_64-consolidate-tsc-calibration.patch
> > i386-prepare-sharing-hpet-code.patch
> > i386-hpet-add-x8664-hpet-bits.patch
> > i386-prepare-sharing-pit-code.patch
> > x86_64-use-i386-i8253-h.patch
> > x86_64-preparatory-apic-set-lvtt.patch
> > x86_64-apic-remove-bogus-pit-synchronization.patch
> > x86_64-apic-shuffle-calibration-around.patch
> > x86_64-apic-calibration-remove-divisor.patch
> > x86_64-apic-change-setup-calling-convention.patch
> > x86_64-apic-remove-nested-irq-disable.patch
> > x86_64-prep-idle-loop-for-dynticks.patch
> > x86_64-apic-add-clockevents-functions.patch
> > x86_64-convert-to-clockevents.patch
> > x86_64-remove-unused-code.patch
> > x86_64-cleanup-apic-c.patch
> > x86_64-cleanup-apic-c-fix.patch
> > x86_64-cleanup-apic-c-fix-2.patch
> > jiffies-remove-unused-macros.patch
> > acpi-remove-the-useless-ifdef-code.patch
> > i386-pit-remove-the-useless-ifdefs.patch
> > i386-hpet-sharing-optimize.patch
> > ich-force-hpet-make-generic-time-capable-of-switching-broadcast-timer.patch
> > ich-force-hpet-restructure-hpet-generic-clock-code.patch
> > ich-force-hpet-ich7-or-later-quirk-to-force-detect-enable.patch
> > ich-force-hpet-ich7-or-later-quirk-to-force-detect-enable-fix.patch
> > ich-force-hpet-late-initialization-of-hpet-after-quirk.patch
> > ich-force-hpet-ich5-quirk-to-force-detect-enable.patch
> > ich-force-hpet-ich5-quirk-to-force-detect-enable-fix.patch
> > ich-force-hpet-ich5-fix-a-bug-with-suspend-resume.patch
> > ich-force-hpet-add-ich7_0-pciid-to-quirk-list.patch
> > x86-fix-cpu_to_node-references.patch
> > x86-convert-cpu_core_map-to-be-a-per-cpu-variable.patch
> > convert-cpu_sibling_map-to-be-a-per-cpu-variable.patch
> > convert-cpu_sibling_map-to-a-per_cpu-data-array-ia64.patch
> > # convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64.patch: busted
> > convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64.patch
> > convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64-fix.patch
> > convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64-fix-2.patch
> > convert-cpu_sibling_map-to-a-per_cpu-data-array-sparc64.patch
> 
> These are fine to me, but should not all go through my tree
> because most changes are in other architectures.

I assume you're referring to just
convert-cpu_sibling_map-to-be-a-per-cpu-variable* here.

> > x86-convert-x86_cpu_to_apicid-to-be-a-per-cpu-variable.patch
> > x86-convert-cpu_llc_id-to-be-a-per-cpu-variable.patch
> > x86-acpi-use-cpu_physical_id.patch
> > i386-visws-extern-inline-static-inline.patch
> > i386-cleanup-struct-irqaction-initializers.patch
> > x86_64-cleanup-struct-irqaction-initializers.patch
> > asm-i386-ioh-fix-constness.patch
> > optimize-x86-page-faults-like-all-other-achitectures-and-kill-notifier-cruft.patch
> > optimize-x86-page-faults-like-all-other-achitectures-and-kill-notifier-cruft-fix.patch
> > hpet-force-enable-on-vt8235-37-chipsets.patch
> > x86_64-check-msr-to-get-mmconfig-for-amd-family-10h-opteron.patch
> > x86_64-check-and-enable-mmconfig-for-amd-family-10h-opteron.patch
> > x86_64-check-and-enable-mmconfig-for-amd-family-10h-opteron-fix.patch
> > x86_64-set-cfg_size-for-amd-family-10h-in-case-mmconfig-is.patch
> > x86_64-set-cfg_size-for-amd-family-10h-in-case-mmconfig-is-fix.patch
> > voyager-dont-try-to-support-unprocessor-builds.patch
> > x86_64-nx-bit-handling-in-change_page_attr.patch
> > x86-64-calgary-fix-calgary=disable=busnum-for-calioc2.patch
> > x86-64-calgary-get-rid-of-translate_phb.patch
> > x86_64-vdso-linker-script-cleanup.patch
> > x86_64-vdso-put-vars-in-rodata.patch
> > x86-convert-cpuinfo_x86-array-to-a-per_cpu-array.patch
> > x86_64-nmi_watchdog-fix-to-be-more-like-i386.patch
> > x86_64-nmi_watchdog-fix-to-be-more-like-i386-fix.patch
> > pci-use-pci=bfsort-for-hp-dl385-g2-dl585-g2.patch
> > 
> >   Send to Andi
> 
> Did you resend it?

"Send", not "Sent".

> I have nothing pending currently. I rejected
> also quite a few of these.

You did?  I'd have dropped them if you had.

Oh well, I was planning on a maintainer patch-bombing tomorrow - let's go
through them again.

> The clockevents patches are not included in this; but given the recent
> trouble i'm not 100% sure they are even ready yet.

hm, well, I hope you and Thomas are on the same page regarding precisely
what the remaining issues are.

> > sparsemem-clean-up-spelling-error-in-comments.patch
> > sparsemem-record-when-a-section-has-a-valid-mem_map.patch
> > sparsemem-record-when-a-section-has-a-valid-mem_map-fix.patch
> > generic-virtual-memmap-support-for-sparsemem.patch
> > generic-virtual-memmap-support-for-sparsemem-fix.patch
> > generic-virtual-memmap-support-for-sparsemem-remove-excess-debugging.patch
> > generic-virtual-memmap-support-for-sparsemem-simplify-initialisation-code-and-reduce-duplication.patch
> > generic-virtual-memmap-support-for-sparsemem-pull-out-the-vmemmap-code-into-its-own-file.patch
> > generic-virtual-memmap-support-vmemmap-generify-initialisation-via-helpers.patch
> > x86_64-sparsemem_vmemmap-2m-page-size-support.patch
> > x86_64-sparsemem_vmemmap-2m-page-size-support-ensure-end-of-section-memmap-is-initialised.patch
> > x86_64-sparsemem_vmemmap-vmemmap-x86_64-convert-to-new-helper-based-initialisation.patch
> > ia64-sparsemem_vmemmap-16k-page-size-support.patch
> > ia64-sparsemem_vmemmap-16k-page-size-support-convert-to-new-helper-based-initialisation.patch
> > sparc64-sparsemem_vmemmap-support.patch
> > sparc64-sparsemem_vmemmap-support-vmemmap-convert-to-new-config-options.patch
> > ppc64-sparsemem_vmemmap-support.patch
> > ppc64-sparsemem_vmemmap-support-vmemmap-ppc64-convert-vmm_-macros-to-a-real-function.patch
> > ppc64-sparsemem_vmemmap-support-vmemmap-ppc64-convert-vmm_-macros-to-a-real-function-fix.patch
> > ppc64-sparsemem_vmemmap-support-convert-to-new-config-options.patch
> > 
> >   virtual memmap: merge
> 
> Hmm, need to recheck the x86_64 bits I think.

Thanks.

> > memoryless-nodes-generic-management-of-nodemasks-for-various-purposes.patch
> > memoryless-nodes-generic-management-of-nodemasks-for-various-purposes-fix.patch
> > memoryless-nodes-introduce-mask-of-nodes-with-memory.patch
> > memoryless-nodes-introduce-mask-of-nodes-with-memory-fix.patch
> > # update-n_high_memory-node-state-for-memory-hotadd.patch: fold
> > update-n_high_memory-node-state-for-memory-hotadd.patch
> > update-n_high_memory-node-state-for-memory-hotadd-fix.patch
> > memoryless-nodes-fix-interleave-behavior-for-memoryless-nodes.patch
> > memoryless-nodes-oom-use-n_high_memory-map-instead-of-constructing-one-on-the-fly.patch
> > memoryless-nodes-no-need-for-kswapd.patch
> > memoryless-nodes-slab-support.patch
> > memoryless-nodes-slub-support.patch
> > memoryless-nodes-uncached-allocator-updates.patch
> > memoryless-nodes-allow-profiling-data-to-fall-back-to-other-nodes.patch
> > memoryless-nodes-update-memory-policy-and-page-migration.patch
> > memoryless-nodes-add-n_cpu-node-state.patch
> > memoryless-nodes-add-n_cpu-node-state-move-setup-of-n_cpu-node-state-mask.patch
> > memoryless-nodes-drop-one-memoryless-node-boot-warning.patch
> > memoryless-nodes-fix-gfp_thisnode-behavior.patch
> > memoryless-nodes-use-n_high_memory-for-cpusets.patch
> > memoryless-nodes-fixup-uses-of-node_online_map-in-generic-code.patch
> > memoryless-nodes-fixup-uses-of-node_online_map-in-generic-code-fix.patch
> > memoryless-nodes-fixup-uses-of-node_online_map-in-generic-code-fix-2.patch
> > memoryless-nodes-fixup-uses-of-node_online_map-in-generic-code-fix-2-3.patch
> > fix-panic-of-cpu-online-with-memory-less-node.patch
> > 
> >   Merge
> 
> At least I still believe the whole concept of memoryless node is dubious.
> 

How come?  Memoryless node can and do occur in real-world machines.  Kernel
should support that?

> 
> > maps2-add-proc-pid-pagemap-interface.patch
> 
> + * For each page in the address space, this file contains one long
> + * representing the corresponding physical page frame number (PFN) or
> 
> The interface is clearly not compat clean at all

Well that would be bad.

What's the issue here?  Both 32-bit and 64-bit userspace will see 64-bit
data.  So the problem is that 32-bit applications on 32-bit kernels will
see 32-bit data but 32-bit applications on 64-bit kernels will see 64-bit
data?

If so, that might be OK - the app just needs a reliable way of working out
whether it's on a 32- or 64-bit kernel?

> > x86_64-efi-boot-support-efi-frame-buffer-driver.patch
> > x86_64-efi-boot-support-efi-boot-document.patch
> 
> This required changes from review I think. And the previous patch is useless
> without a boot protocol.

So should I drop them?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists