Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754475Ab2BWTHe (ORCPT ); Thu, 23 Feb 2012 14:07:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:15366 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753529Ab2BWTHc (ORCPT ); Thu, 23 Feb 2012 14:07:32 -0500 Date: Thu, 23 Feb 2012 14:07:23 -0500 From: Dave Jones To: Linux Kernel , "Paul E. McKenney" , bskeggs@redhat.com Subject: Re: 3.3-rc4 slub debug / rcu slowness, traces. Message-ID: <20120223190722.GA21407@redhat.com> Mail-Followup-To: Dave Jones , Linux Kernel , "Paul E. McKenney" , bskeggs@redhat.com References: <20120223181438.GC26722@redhat.com> <20120223184143.GD26722@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120223184143.GD26722@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4082 Lines: 81 On Thu, Feb 23, 2012 at 01:41:44PM -0500, Dave Jones wrote: > This machine has switchable graphics. It's possible that I never noticed this before > because I had it switched onto Intel graphics when I used to use this laptop, so it > may have been there for a while. > > I'm unclear on why disabling slub_debug makes the problem go away. > Perhaps wherever nouveau is spinning is just allocation heavy ? > I'll do some profiling. So that'll be all the ACPI allocations/free's while it parses the rom. modprobe R running task 2920 2513 2387 0x00000080 ffff8800813954d8 0000000000000046 000000000000c8a0 ffff8800b39da4a0 ffff880081395518 ffff880081395fd8 ffff880081395fd8 ffff880081395fd8 ffff88008f98a4a0 ffff8800b39da4a0 ffff8800813954c8 ffff880081395fd8 Call Trace: [] ? acpi_os_release_object+0xe/0x12 [] preempt_schedule_irq+0x4b/0x80 [] retint_kernel+0x26/0x30 [] ? free_debug_processing+0x19f/0x1d3 [] ? _raw_spin_unlock_irqrestore+0x6d/0x90 [] __slab_free+0x2e/0x1de [] ? _raw_spin_unlock_irqrestore+0x4a/0x90 [] ? debug_check_no_obj_freed+0x17f/0x230 [] ? acpi_os_release_object+0xe/0x12 [] ? acpi_os_release_object+0xe/0x12 [] kmem_cache_free+0x240/0x250 [] acpi_os_release_object+0xe/0x12 [] acpi_ps_free_op+0x64/0x6b [] ? acpi_ps_get_arg+0x1b/0x48 [] acpi_ps_delete_parse_tree+0x3e/0x60 [] acpi_ps_complete_this_op+0x186/0x192 [] acpi_ps_complete_op+0x2e/0x2b4 [] ? acpi_ds_exec_end_op+0x548/0x57a [] acpi_ps_parse_loop+0x8b4/0xa48 [] ? acpi_ut_create_generic_state+0x37/0x54 [] acpi_ps_parse_aml+0x10c/0x381 [] acpi_ps_execute_method+0x20e/0x2f0 [] acpi_ns_evaluate+0x190/0x2d7 [] acpi_evaluate_object+0x16a/0x2ae [] ? kfree+0x286/0x2a0 [] nouveau_acpi_get_bios_chunk+0x73/0xd0 [nouveau] [] load_vbios_acpi+0x37/0x50 [nouveau] [] nouveau_bios_init+0x12e/0x1620 [nouveau] [] ? trace_hardirqs_on_caller+0x10d/0x1a0 [] nouveau_card_init+0x918/0x1640 [nouveau] [] nouveau_load+0x443/0x7d0 [nouveau] [] drm_get_pci_dev+0x199/0x2b0 [drm] [] nouveau_pci_probe+0x10/0x12 [nouveau] [] local_pci_probe+0x5c/0xd0 [] pci_device_probe+0x109/0x130 [] driver_probe_device+0x9c/0x300 [] __driver_attach+0xab/0xb0 [] ? driver_probe_device+0x300/0x300 [] bus_for_each_dev+0x5e/0x90 [] driver_attach+0x1e/0x20 [] bus_add_driver+0x1c0/0x2b0 [] driver_register+0x76/0x140 [] ? __raw_spin_lock_init+0x38/0x70 [] __pci_register_driver+0x66/0xe0 [] drm_pci_init+0x11a/0x130 [drm] [] ? vga_switcheroo_register_handler+0x3c/0x60 [] ? 0xffffffffa07e4fff [] nouveau_init+0x4f/0x1000 [nouveau] [] do_one_initcall+0x129/0x170 [] sys_init_module+0xb92/0x20d0 [] system_call_fastpath+0x16/0x1b I suspect the way out of this would be to move the bios parsing out of the module init path. No idea why it's such an unbearably slow operation on this machine though. Blame Sony I guess. thoughts? Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/