From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Michael Ellerman <mpe@ellerman.id.au>,
Hamish Martin <hamish.martin@alliedtelesis.co.nz>,
paulus@samba.org
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 0/2] Allow configurable stack size (especially 32k on PPC64)
Date: Wed, 22 Feb 2017 19:06:33 +1100 [thread overview]
Message-ID: <1487750793.23576.219.camel@kernel.crashing.org> (raw)
In-Reply-To: <871suqn3m7.fsf@concordia.ellerman.id.au>
On Wed, 2017-02-22 at 17:25 +1100, Michael Ellerman wrote:
>
> Thanks for the detailed explanation.
>
> The patches look fine, so I don't see any reason why we wouldn't merge
> this. I might make the config option depend on EXPERT, but that's just
> cosmetic.
>
>
> You're right about the difference in stack overhead between 32 & 64-bit.
> But I guess on the other hand we've been using 16K stacks on 64-bit for
> over 15 years, and although we have had some reports of stack overflow
> they're not a common problem.
Right and in fact I wonder if we could generally help this for cases
like this one (lots of stacked devices) by having the generic driver
core break those chains by deferring new device registration to a work
queue or kthread.
That would help in a lot of cases. We do get some stupid deep chains
in cases of many bus encapsulation.
Cheers,
Ben.
next prev parent reply other threads:[~2017-02-22 8:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-20 20:24 [PATCH 0/2] Allow configurable stack size (especially 32k on PPC64) Hamish Martin
2017-02-20 20:24 ` [PATCH 1/2] powerpc: Move THREAD_SHIFT config to KConfig Hamish Martin
2017-02-20 20:24 ` [PATCH 2/2] powerpc64: Allow for THREAD_SIZE > 16k Hamish Martin
2017-02-21 12:51 ` [PATCH 0/2] Allow configurable stack size (especially 32k on PPC64) Gabriel Paubert
2017-02-21 22:31 ` Benjamin Herrenschmidt
2017-02-22 6:25 ` Michael Ellerman
2017-02-22 8:06 ` Benjamin Herrenschmidt [this message]
2017-02-24 0:40 ` Hamish Martin
2017-02-24 0:35 ` Hamish Martin
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=1487750793.23576.219.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=hamish.martin@alliedtelesis.co.nz \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.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).