linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: "Michael Ellerman" <mpe@ellerman.id.au>,
	"Michal Suchánek" <msuchanek@suse.de>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 4/4] powerpc/64s: Support shrinking the SLB for debugging
Date: Wed, 23 Jan 2019 18:40:05 +1000	[thread overview]
Message-ID: <1548232654.t0vcx3nv0o.astroid@bobo.none> (raw)
In-Reply-To: <87won12b92.fsf@concordia.ellerman.id.au>

Michael Ellerman's on January 19, 2019 8:27 pm:
> Michal Suchánek <msuchanek@suse.de> writes:
> 
>> On Thu, 17 Jan 2019 23:13:28 +1100
>> Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>>> On machines with 1TB segments and a 32-entry SLB it's quite hard to
>>> cause sufficient SLB pressure to trigger bugs caused due to badly
>>> timed SLB faults.
>>> 
>>> We have seen this in the past and a few years ago added the
>>> disable_1tb_segments command line option to force the use of 256MB
>>> segments. However even this allows some bugs to slip through testing
>>> if the SLB entry in question was recently accessed.
>>> 
>>> So add a new command line parameter for debugging which shrinks the
>>> SLB to the minimum size we can support. Currently that size is 3, two
>>> bolted SLBs and 1 for dynamic use. This creates the maximal SLB
>>
>> Doesn't this violate the power of 2 requirement stated in 2/4?
> 
> Yes. Good point. This was originally a hack patch in my tree, back when
> SLB_NUM_BOLTED was 3 and before Nick even added the slb_used_bitmap, so
> back then it was a power of 2 but it also didn't matter :)
> 
> I think I'll rework the slb_full_bitmap patch anyway and remove the
> power of 2 requirement, so then this patch will be OK.

Thanks, good patch and really will help testing. Sometimes even if you 
can get enough pressure with the 256MB segments, you actually want to 
test 1TB segment code paths too.

Thanks,
Nick


  reply	other threads:[~2019-01-23  8:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17 12:13 [PATCH 1/4] powerpc/64s: Always set mmu_slb_size using slb_set_size() Michael Ellerman
2019-01-17 12:13 ` [PATCH 2/4] powerpc/64s: Add slb_full_bitmap rather than hard-coding U32_MAX Michael Ellerman
2019-01-17 16:30   ` Segher Boessenkool
2019-01-18 12:28     ` Michael Ellerman
2019-01-18 23:12       ` Segher Boessenkool
2019-01-23  9:02   ` Aneesh Kumar K.V
2019-01-17 12:13 ` [PATCH 3/4] powerpc/64s: Move SLB init into hash_utils_64.c Michael Ellerman
2019-01-23  9:04   ` Aneesh Kumar K.V
2019-01-17 12:13 ` [PATCH 4/4] powerpc/64s: Support shrinking the SLB for debugging Michael Ellerman
2019-01-19  0:13   ` Michal Suchánek
2019-01-19 10:27     ` Michael Ellerman
2019-01-23  8:40       ` Nicholas Piggin [this message]
2019-01-23  9:10   ` Aneesh Kumar K.V
2019-01-23  8:59 ` [PATCH 1/4] powerpc/64s: Always set mmu_slb_size using slb_set_size() Aneesh Kumar K.V

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=1548232654.t0vcx3nv0o.astroid@bobo.none \
    --to=npiggin@gmail.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=msuchanek@suse.de \
    /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).