lkml.org 
[lkml]   [2013]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Possible regression with cgroups in 3.11
On Wed, Nov 20, 2013 at 9:47 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> [+cc Jiri]
>
> On Wed, Nov 20, 2013 at 9:26 PM, Sasha Levin <sasha.levin@oracle.com> wrote:
>> On 11/18/2013 03:39 PM, Bjorn Helgaas wrote:
>>>
>>> On Mon, Nov 18, 2013 at 11:29:32AM -0800, Yinghai Lu wrote:
>>>>
>>>> On Mon, Nov 18, 2013 at 10:14 AM, Bjorn Helgaas <bhelgaas@google.com>
>>>> wrote:
>>>>>>
>>>>>> A bit of comment here would be nice but yeah I think this should work.
>>>>>> Can you please also queue the revert of c2fda509667b ("workqueue:
>>>>>> allow work_on_cpu() to be called recursively") after this patch?
>>>>>> Please feel free to add my acked-by.
>>>>>
>>>>>
>>>>> OK, below are the two patches (Alex's fix + the revert) I propose to
>>>>> merge. Unless there are objections, I'll ask Linus to pull these
>>>>> before v3.13-rc1.
>>>>>
>>>>>
>>>>>
>>>>> commit 84f23f99b507c2c9247f47d3db0f71a3fd65e3a3
>>>>> Author: Alexander Duyck <alexander.h.duyck@intel.com>
>>>>> Date: Mon Nov 18 10:59:59 2013 -0700
>>>>>
>>>>> PCI: Avoid unnecessary CPU switch when calling driver .probe()
>>>>> method
>>>>>
>>>>> If we are already on a CPU local to the device, call the driver
>>>>> .probe()
>>>>> method directly without using work_on_cpu().
>>>>>
>>>>> This is a workaround for a lockdep warning in the following
>>>>> scenario:
>>>>>
>>>>> pci_call_probe
>>>>> work_on_cpu(cpu, local_pci_probe, ...)
>>>>> driver .probe
>>>>> pci_enable_sriov
>>>>> ...
>>>>> pci_bus_add_device
>>>>> ...
>>>>> pci_call_probe
>>>>> work_on_cpu(cpu, local_pci_probe, ...)
>>>>>
>>>>> It would be better to fix PCI so we don't call VF driver .probe()
>>>>> methods
>>>>> from inside a PF driver .probe() method, but that's a bigger
>>>>> project.
>>>>>
>>>>> [bhelgaas: disable preemption, open bugzilla, rework comments &
>>>>> changelog]
>>>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=65071
>>>>> Link:
>>>>> http://lkml.kernel.org/r/CAE9FiQXYQEAZ=0sG6+2OdffBqfLS9MpoN1xviRR9aDbxPxcKxQ@mail.gmail.com
>>>>> Link:
>>>>> http://lkml.kernel.org/r/20130624195942.40795.27292.stgit@ahduyck-cp1.jf.intel.com
>>>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>>>>> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>>>>> Acked-by: Tejun Heo <tj@kernel.org>
>>>>
>>>>
>>>> Tested-by: Yinghai Lu <yinghai@kernel.org>
>>>> Acked-by: Yinghai Lu <yinghai@kernel.org>
>>>
>>>
>>> Thanks, I added these and pushed my for-linus branch for -next to
>>> pick up before I ask Linus to pull them.
>>
>>
>> Hi guys,
>>
>> This patch seems to be causing virtio (wouldn't it happen with any other
>> driver too?) to give
>> the following spew:
>
> Yep, Jiri Slaby reported this earlier. I dropped those patches for
> now. Yinghai and I both tested this without incident, but we must
> have tested quite the same scenario you did.
>
> I'll look at this more tomorrow. My first thought is that it's
> probably silly to worry about preemption when checking the node. It's
> unlikely that we'd be preempted (probably not even possible except at
> hot add-time), and the worst that can happen is we run the .probe()
> method on the wrong node, which means worse performance but correct
> functionality.

I dropped the preempt_disable() and re-added this to my for-linus
branch. Let me know if you see any more issues.

Bjorn


\
 
 \ /
  Last update: 2013-11-25 23:21    [W:0.051 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site