linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Prarit Bhargava <prarit@redhat.com>
To: "Yu, Fenghua" <fenghua.yu@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH] x86: Add check for number of available vectors before CPU down
Date: Wed, 04 Dec 2013 10:15:52 -0500	[thread overview]
Message-ID: <529F4728.20500@redhat.com> (raw)
In-Reply-To: <3E5A0FA7E9CA944F9D5414FEC6C712205A59505E@ORSMSX106.amr.corp.intel.com>



On 12/03/2013 06:42 PM, Yu, Fenghua wrote:
> 
> 
>> -----Original Message-----
>> From: Prarit Bhargava [mailto:prarit@redhat.com]
>>
>> Second try at this ...
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64791
>>
>> When a cpu is downed on a system, the irqs on the cpu are assigned to
>> other cpus.  It is possible, however, that when a cpu is downed there
>> aren't enough free vectors on the remaining cpus to account for the
>> vectors from the cpu that is being downed.
>>
>> This results in an interesting "overflow" condition where irqs are
>> "assigned" to a CPU but are not handled.
>>
>> For example, when downing cpus on a 1-64 logical processor system:
>>
>> +			if (per_cpu(vector_irq, cpu)[vector] < 0)
>> +				count++;
> 
> But later on fixup_irqs will set some of vector_irq vector as -1 on this
> to-be-disabled cpu. That will release vectors assigned to this cpu. So
> checking vector_irq at this point before fixup_irqs doesn't make sense, right?
> 

Fenghua, IIUC the purpose of fixup_irqs() is to migrate irqs from the
to-be-disabled cpu to other cpus by using affinity, etc..  The to-be-disabled
cpus' irqs are set to -1, however, only after they are migrated off to an
enabled cpu.

This check I'm introducing is well before that stage in effort to determine
whether or not the system has "room" for the irqs on the remaining cpus.

So I think that the check is in the right spot.  We should do it early.  I
suppose an argument could be made to do the check in fixup_irqs(), however, my
feeling is by then it is very late in the process of downing the cpu.

I noticed a subtle bug in my patch that I will send with a [v2].  I'm not taking
into account per-cpu interrupts in the check_vectors() function.

P.

> Thanks.
> 
> -Fenghua
> 

  reply	other threads:[~2013-12-04 15:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-19 16:24 [PATCH] x86: Add check for number of available vectors before CPU down Prarit Bhargava
2013-12-03 23:42 ` Yu, Fenghua
2013-12-04 15:15   ` Prarit Bhargava [this message]
2013-12-04  2:48 ` rui wang
2013-12-18 19:28   ` Prarit Bhargava
2013-12-19  7:19     ` rui wang
2013-12-19 13:33       ` Prarit Bhargava
2013-12-19 19:03       ` Prarit Bhargava
  -- strict thread matches above, loose matches on Subject: below --
2013-12-02 13:18 Prarit Bhargava
2013-11-11 16:00 Prarit Bhargava

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=529F4728.20500@redhat.com \
    --to=prarit@redhat.com \
    --cc=fenghua.yu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).