All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.