public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	Yinghai Lu <yinghai@kernel.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [RFC] Correct behaviour of irq affinity?
Date: Wed, 25 Mar 2009 11:03:08 +1030	[thread overview]
Message-ID: <200903251103.10249.rusty@rustcorp.com.au> (raw)
In-Reply-To: <m1k56frt6e.fsf@fess.ebiederm.org>

On Tuesday 24 March 2009 23:09:37 Eric W. Biederman wrote:
> desc->affinity should be what the user requested, if it is at all
> possible to honor the user space request.  YH the fact that we do not
> currently exercise the full freedom that user space gives us is
> irrelevant.

Yep, OK.

> YH has a point that several of the implementations of
> cpu_mask_to_apic_id do not take cpu_online_map into account and should
> probably be fixed.  flat_cpu_mask_to_apicid was the one I could find.

Also the numaq apic.h.  I'll do an audit and send a patch.

> Also now that I look at it there is one other bug in this routine
> that you have missed.  set_extra_move_desc should be called before
> we set desc->affinity, as it compares that with the new value to
> see if we are going to be running on a new cpu, and if so we may
> need to reallocate irq_desc onto a new numa node.  set_extra_move_desc
> looks a little fishy but it doesn't stand a chance if it is called
> with the wrong data.

Yes, agree with Yinghai's fix.  I'll re-spin my patch on top of his.

Thanks for looking at this!
Rusty.

  parent reply	other threads:[~2009-03-25  0:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-24  5:49 [RFC] Correct behaviour of irq affinity? Rusty Russell
2009-03-24  7:21 ` Yinghai Lu
2009-03-24 12:52   ` Rusty Russell
2009-03-24 20:36     ` Yinghai Lu
2009-03-24 12:39 ` Eric W. Biederman
2009-03-24 19:49   ` Yinghai Lu
2009-03-24 20:23   ` [PATCH] x86: fix set_extra_move_desc calling Yinghai Lu
2009-03-24 21:15     ` [tip:x86/apic] " Yinghai Lu
2009-03-24 21:15     ` [PATCH 1/3] " Yinghai Lu
2009-03-24 21:16       ` [PATCH 2/3] x86: use default_cpu_mask_to_apicid for 64bit Yinghai Lu
2009-03-24 21:30         ` [tip:x86/apic] " Yinghai Lu
2009-03-24 21:34           ` Ingo Molnar
2009-03-24 21:42             ` [PATCH 3/3] x86: Correct behaviour of irq affinity -v2 Yinghai Lu
2009-03-24 21:17       ` [PATCH 3/3] x86: Correct behaviour of irq affinity Yinghai Lu
2009-03-24 21:30         ` [tip:x86/apic] " Rusty Russell
2009-03-25 17:51         ` Rusty Russell
2009-03-25  0:33   ` Rusty Russell [this message]
2009-03-25  0:59     ` [RFC] Correct behaviour of irq affinity? Rusty Russell
2009-03-25  1:03       ` Yinghai Lu

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=200903251103.10249.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=x86@kernel.org \
    --cc=yinghai@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