All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Cliff Wickman <cpw@sgi.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	Jack Steiner <steiner@sgi.com>, Mike Travis <travis@sgi.com>
Subject: Re: [PATCH 3/3] x86: UV2 BAU hang workarounds
Date: Mon, 25 Jun 2012 12:03:21 +0200	[thread overview]
Message-ID: <20120625100321.GB27081@gmail.com> (raw)
In-Reply-To: <20120622131459.GC31884@sgi.com>


* Cliff Wickman <cpw@sgi.com> wrote:

> On SGI's UV2 the BAU (Broadcast Assist Unit) driver can hang under a
> heavy load.  To cure this: 
> 
> - Disable the UV2 extended status mode (see UV2_EXT_SHFT), as this
>   mode changes BAU behavior in more ways then just delivering an extra bit
>   of status.  Revert status to just two meaningful bits, like UV1.
> - Use no IPI-style resets on UV2.  Just give up the request for whatever the
>   reason it failed and let it be accomplished with the legacy IPI method.
> - Use no alternate sending descriptor (the former UV2 workaround
>   bcp->using_desc and handle_uv2_busy() stuff).  Just disable the use of the
>   BAU for a period of time in favor of the legacy IPI method when the h/w bug
>   leaves a descriptor busy.
>   -- new tunable: giveup_limit determines the threshold at which a hub is 
>      so plugged that it should do all requests with the legacy IPI method for a
>      period of time
>   -- generalize disable_for_congestion() (renamed disable_for_period()) for
>      use whenever a hub should avoid using the BAU for a period of time
> 
> Misc:
> - fix find_another_by_swack(), which is part of the UV2 bug workaround
> - correct and clarify the statistics (new stats s_overipilimit s_giveuplimit
>   s_enters s_ipifordisabled s_plugged s_congested)

Sigh, it looks like something that ought to be 7 successive, 
easy to review commits got mixed up into a single, huge, hard to 
review commit. How did that happen?

Thanks,

	Ingo

  reply	other threads:[~2012-06-25 10:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-22 13:09 [PATCH 0/3] x86, UV: BAU additions and fixes Cliff Wickman
2012-06-22 13:12 ` [PATCH 1/3] x86: UV BAU destination timeout period Cliff Wickman
2012-06-26  5:59   ` [tip:x86/uv] x86/uv: Fix the " tip-bot for Cliff Wickman
2012-06-22 13:13 ` [PATCH 2/3] x86: UV BAU runtime enable and disable Cliff Wickman
2012-06-26  5:59   ` [tip:x86/uv] x86/uv: Implement UV BAU runtime enable and disable control via /proc/sgi_uv/ tip-bot for Cliff Wickman
2012-06-22 13:14 ` [PATCH 3/3] x86: UV2 BAU hang workarounds Cliff Wickman
2012-06-25 10:03   ` Ingo Molnar [this message]
2012-06-25 12:36     ` Cliff Wickman
2012-06-25 12:40       ` Ingo Molnar
2012-06-26  6:00   ` [tip:x86/uv] x86/uv: Work around UV2 BAU hangs tip-bot for Cliff Wickman

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=20120625100321.GB27081@gmail.com \
    --to=mingo@kernel.org \
    --cc=cpw@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=steiner@sgi.com \
    --cc=travis@sgi.com \
    --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 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.