On Wed, 20 Dec 2017, John Baldwin wrote:
On Wednesday, December 20, 2017 10:16:58 AM Nathan Whitehorn wrote:
...
With GCC 4, it takes a little while, but trying to build ports over NFS
is a sure-fire way to bring down the kernel. I haven't tried any other
compilers.
Ah, I have only done thing
On Wed, Dec 20, 2017 at 12:15 PM, Adrian Chadd wrote:
> Hi,
>
> I kinda bet that this will just get worse over time, so maybe it's
> time we revisited figuring out a better way of dispatching work
> instead of (a) lots of kernel threads for different subsystems and (b)
> lots of deep stack frames
Hi,
I kinda bet that this will just get worse over time, so maybe it's
time we revisited figuring out a better way of dispatching work
instead of (a) lots of kernel threads for different subsystems and (b)
lots of deep stack frames.
eg - NFS over wifi == hilarious pain
-adrian
___
On Wednesday, December 20, 2017 10:16:58 AM Nathan Whitehorn wrote:
>
> On 12/20/17 09:14, John Baldwin wrote:
> > On Wednesday, December 20, 2017 09:59:26 AM David Chisnall wrote:
> >> On 16 Dec 2017, at 18:05, John Baldwin wrote:
> >>> When I build a FreeBSD/mips64 kernel with clang,
> >>> _any
On 12/20/17 09:14, John Baldwin wrote:
On Wednesday, December 20, 2017 09:59:26 AM David Chisnall wrote:
On 16 Dec 2017, at 18:05, John Baldwin wrote:
When I build a FreeBSD/mips64 kernel with clang,
_any_ simple NFS op triggers a kernel stack overflow. Kernels compiled
with GCC do not.
Th
On Wednesday, December 20, 2017 09:59:26 AM David Chisnall wrote:
> On 16 Dec 2017, at 18:05, John Baldwin wrote:
> >
> > When I build a FreeBSD/mips64 kernel with clang,
> > _any_ simple NFS op triggers a kernel stack overflow. Kernels compiled
> > with GCC do not.
>
> That is not my experienc
On 16 Dec 2017, at 18:05, John Baldwin wrote:
>
> When I build a FreeBSD/mips64 kernel with clang,
> _any_ simple NFS op triggers a kernel stack overflow. Kernels compiled
> with GCC do not.
That is not my experience. I haven’t tried a MIPS64 kernel built with clang,
but with in-tree gcc I ge
On 12/12/17 11:32, John Baldwin wrote:
On 12/11/17 5:26 AM, Eugene Grosbein wrote:
On 11.12.2017 16:19, Konstantin Belousov wrote:
On Mon, Dec 11, 2017 at 04:32:37AM +, Conrad Meyer wrote:
Author: cem
Date: Mon Dec 11 04:32:37 2017
New Revision: 326758
URL: https://svnweb.freebsd.org/cha
On 12/14/17 3:34 AM, Eugene Grosbein wrote:
> On 13.12.2017 04:55, John Baldwin wrote:
>> On 12/12/17 3:09 PM, Eugene Grosbein wrote:
>>> On 13.12.2017 02:32, John Baldwin wrote:
>>>
Certainly for MIPS I have found that compiling with clang
instead of gcc for mips64 gives a kernel that pa
14.12.2017 23:00, Konstantin Belousov wrote:
> Sigh. This would make i386 even less usable for everybody, perhaps
> except you. Because default 3G of UVA is too small for some common tasks
> (thanks clang, but also e.g. pypy), and you reduce the user address
> space even more.
On Thu, Dec 14, 2017 at 10:39:18PM +0700, Eugene Grosbein wrote:
> On 14.12.2017 22:23, Konstantin Belousov wrote:
>
> >>> Sigh. This would make i386 even less usable for everybody, perhaps
> >>> except you. Because default 3G of UVA is too small for some common tasks
> >>> (thanks clang, but also
On 14.12.2017 22:23, Konstantin Belousov wrote:
>>> Sigh. This would make i386 even less usable for everybody, perhaps
>>> except you. Because default 3G of UVA is too small for some common tasks
>>> (thanks clang, but also e.g. pypy), and you reduce the user address
>>> space even more.
>>
>> Tho
On Thu, Dec 14, 2017 at 07:59:03PM +0700, Eugene Grosbein wrote:
> On 14.12.2017 19:26, Konstantin Belousov wrote:
>
> > Sigh. This would make i386 even less usable for everybody, perhaps
> > except you. Because default 3G of UVA is too small for some common tasks
> > (thanks clang, but also e.g.
On 14.12.2017 19:26, Konstantin Belousov wrote:
> Sigh. This would make i386 even less usable for everybody, perhaps
> except you. Because default 3G of UVA is too small for some common tasks
> (thanks clang, but also e.g. pypy), and you reduce the user address
> space even more.
Those who need 3
On Thu, Dec 14, 2017 at 07:04:57PM +0700, Eugene Grosbein wrote:
> On 14.12.2017 18:51, Konstantin Belousov wrote:
>
> >> I think thats's NFS code who is guilty. You can see example of amd64
> >> (sic!) kstack exhaustion
> >> due to 40+ frames deep call chain here:
> >>
> >> https://lists.freebsd
On 14.12.2017 18:51, Konstantin Belousov wrote:
>> I think thats's NFS code who is guilty. You can see example of amd64 (sic!)
>> kstack exhaustion
>> due to 40+ frames deep call chain here:
>>
>> https://lists.freebsd.org/pipermail/freebsd-stable/2017-July/087429.html
>
> Yes, NFS crosses netwo
On Thu, Dec 14, 2017 at 06:34:21PM +0700, Eugene Grosbein wrote:
> On 13.12.2017 04:55, John Baldwin wrote:
> > On 12/12/17 3:09 PM, Eugene Grosbein wrote:
> >> On 13.12.2017 02:32, John Baldwin wrote:
> >>
> >>> Certainly for MIPS I have found that compiling with clang
> >>> instead of gcc for mip
On 14.12.2017 18:34, Eugene Grosbein wrote:
> On 13.12.2017 04:55, John Baldwin wrote:
>> On 12/12/17 3:09 PM, Eugene Grosbein wrote:
>>> On 13.12.2017 02:32, John Baldwin wrote:
>>>
Certainly for MIPS I have found that compiling with clang
instead of gcc for mips64 gives a kernel that pa
On 13.12.2017 04:55, John Baldwin wrote:
> On 12/12/17 3:09 PM, Eugene Grosbein wrote:
>> On 13.12.2017 02:32, John Baldwin wrote:
>>
>>> Certainly for MIPS I have found that compiling with clang
>>> instead of gcc for mips64 gives a kernel that panics for stack overflow for
>>> any
>>> use of NFS
13.12.2017 3:43, Rodney W. Grimes wrote:
> Or are you thinking we have something that is so deep even if it
> only uses 32 bytes of stack we are going to run ourselfs out of
> kstack under some work loads? I hope not.
No, I'm not.
___
svn-src-all@free
> On 13.12.2017 00:32, Rodney W. Grimes wrote:
>
> >> I am not sure if there are tools that can analyze stack requirements for
> >> possible call chains rather than individual functions.
> >
> > Call graphs can be used to find deep chains. Combine the above
> > with a call graph and we should be
[ Charset UTF-8 unsupported, converting... ]
> On 12/12/2017 19:01, Rodney W. Grimes wrote:
> > We should probably start looking for those, something someone who is
> > offerring help but doesnt know what they might be good at, but can
> > read C code. They could be utililized t simply scan throug
On 12/12/17 3:09 PM, Eugene Grosbein wrote:
> On 13.12.2017 02:32, John Baldwin wrote:
>
>> Certainly for MIPS I have found that compiling with clang
>> instead of gcc for mips64 gives a kernel that panics for stack overflow for
>> any
>> use of NFS. It might be that this is due to something MIP
> On 13.12.2017 00:01, Rodney W. Grimes wrote:
>
> >> But many other parts of kernel think it's OK to allocate big arrays or
> >> structures on stack.
> >
> > We should probably start looking for those, something someone who is
> > offerring help but doesnt know what they might be good at, but ca
On 13.12.2017 02:32, John Baldwin wrote:
> Certainly for MIPS I have found that compiling with clang
> instead of gcc for mips64 gives a kernel that panics for stack overflow for
> any
> use of NFS. It might be that this is due to something MIPS-specific, but it
> might be worthwhile retesting w
On 12/11/17 5:26 AM, Eugene Grosbein wrote:
> On 11.12.2017 16:19, Konstantin Belousov wrote:
>> On Mon, Dec 11, 2017 at 04:32:37AM +, Conrad Meyer wrote:
>>> Author: cem
>>> Date: Mon Dec 11 04:32:37 2017
>>> New Revision: 326758
>>> URL: https://svnweb.freebsd.org/changeset/base/326758
>>>
>>
On 13.12.2017 00:32, Rodney W. Grimes wrote:
>> I am not sure if there are tools that can analyze stack requirements for
>> possible call chains rather than individual functions.
>
> Call graphs can be used to find deep chains. Combine the above
> with a call graph and we should be able to come
On 13.12.2017 00:01, Rodney W. Grimes wrote:
>> But many other parts of kernel think it's OK to allocate big arrays or
>> structures on stack.
>
> We should probably start looking for those, something someone who is
> offerring help but doesnt know what they might be good at, but can
> read C cod
On 12/12/2017 19:01, Rodney W. Grimes wrote:
> We should probably start looking for those, something someone who is
> offerring help but doesnt know what they might be good at, but can
> read C code. They could be utililized t simply scan through the
> code looking for this type of thing and bring
[ Charset windows-1252 unsupported, converting... ]
> 12.12.2017 22:30, Rodney W. Grimes:
>
> >>> Now I run FreeBSD 11/i386 as my home router with IPSEC and torrent
> >>> client, and I run several virtualized routers with IPSEC tunnels,
> >>> jabber and mail server, squid and ZFS for src/obj/ports
12.12.2017 22:30, Rodney W. Grimes:
>>> Now I run FreeBSD 11/i386 as my home router with IPSEC and torrent
>>> client, and I run several virtualized routers with IPSEC tunnels,
>>> jabber and mail server, squid and ZFS for src/obj/ports compression
>>> and they all easily crash unless kern.kstack_
> On 12 Dec, Eugene Grosbein wrote:
>
> > Now I run FreeBSD 11/i386 as my home router with IPSEC and torrent
> > client, and I run several virtualized routers with IPSEC tunnels,
> > jabber and mail server, squid and ZFS for src/obj/ports compression
> > and they all easily crash unless kern.kstac
On 12.12.2017 06:00, Don Lewis wrote:
> On 12 Dec, Eugene Grosbein wrote:
>
>> Now I run FreeBSD 11/i386 as my home router with IPSEC and torrent
>> client, and I run several virtualized routers with IPSEC tunnels,
>> jabber and mail server, squid and ZFS for src/obj/ports compression
>> and they
On 12 Dec, Eugene Grosbein wrote:
> Now I run FreeBSD 11/i386 as my home router with IPSEC and torrent
> client, and I run several virtualized routers with IPSEC tunnels,
> jabber and mail server, squid and ZFS for src/obj/ports compression
> and they all easily crash unless kern.kstack_pages rais
12.12.2017 2:12, Rodney W. Grimes wrote:
>>> Not sure about IPSEC and ZFS. But I was NOT able to reproduce the issue by
>>> just using
>>> an SCTP association on a 32-bit VM using FreeBSD 11.1. So right now I don't
>>> know what
>>> is wrong and therefore what could be fixed...
>>
>> You just go
> 12.12.2017 1:52, Michael Tuexen wrote:
>
> > Not sure about IPSEC and ZFS. But I was NOT able to reproduce the issue by
> > just using
> > an SCTP association on a 32-bit VM using FreeBSD 11.1. So right now I don't
> > know what
> > is wrong and therefore what could be fixed...
>
> You just g
12.12.2017 1:52, Michael Tuexen wrote:
> Not sure about IPSEC and ZFS. But I was NOT able to reproduce the issue by
> just using
> an SCTP association on a 32-bit VM using FreeBSD 11.1. So right now I don't
> know what
> is wrong and therefore what could be fixed...
You just got lucky. Kernel s
> On 11. Dec 2017, at 17:21, Eugene Grosbein wrote:
>
> 11.12.2017 22:08, Konstantin Belousov пишет:
>> On Mon, Dec 11, 2017 at 06:03:36PM +0700, Eugene Grosbein wrote:
>>> I do not try to contradict other usage patterns. In fact, I'm eager to know
>>> a practical example of such pattern: a task,
12.12.2017 0:33, Rodney W. Grimes пишет:
> [ Charset UTF-8 unsupported, converting... ]
>> 11.12.2017 23:45, Alexey Dokuchaev wrote:
>>
Understood. While I'm sure that modern internet browsers make it
uncomfortable to browse with less than 4G total RAM (e.g. 2GB) available
for the sy
...
> >
> > We need to break the developers model that i386 is dead and that i386 is
> > not running on extremly modern hardware due to the factor of virtualization.
> >
> > Output from one of my VM's running inside bhyve:
> >
> > # uname -a
> > FreeBSD filestore.dnsmgr.net 11.1-RELEASE FreeBSD
[ Charset UTF-8 unsupported, converting... ]
> 11.12.2017 23:45, Alexey Dokuchaev wrote:
>
> >> Understood. While I'm sure that modern internet browsers make it
> >> uncomfortable to browse with less than 4G total RAM (e.g. 2GB) available
> >> for the system thus requiring amd64,
> >
> > Browsing
11.12.2017 23:45, Alexey Dokuchaev wrote:
>> Understood. While I'm sure that modern internet browsers make it
>> uncomfortable to browse with less than 4G total RAM (e.g. 2GB) available
>> for the system thus requiring amd64,
>
> Browsing just fine on 2G RAM with Firefox, both under GNU/Linux and
On Mon, Dec 11, 2017 at 11:21:06PM +0700, Eugene Grosbein wrote:
> 11.12.2017 22:08, Konstantin Belousov пишет:
> > Plain workstation use, like X11+browser+editor+some other programs easily
> > allocates 1000+ threads. It was still possible to use 32bit x86 for that,
> > of course in max memory co
11.12.2017 22:09, Rodney W. Grimes write:
> THis is a mistake, there is a huge worled of i386 deployment, not all
> the world needs, or even wants amd64, especially in teh virtualization
> world when you are running anything with less than 4G of memory, which
> I would argue is a huge depolyement
11.12.2017 22:08, Konstantin Belousov пишет:
> On Mon, Dec 11, 2017 at 06:03:36PM +0700, Eugene Grosbein wrote:
>> I do not try to contradict other usage patterns. In fact, I'm eager to know
>> a practical example of such pattern: a task, an application, anything real?
> Plain workstation use, like
On Mon, Dec 11, 2017 at 07:33:08AM -0800, Rodney W. Grimes wrote:
> > On Mon, Dec 11, 2017 at 07:09:10AM -0800, Rodney W. Grimes wrote:
> > > The current comment about a pcb, I thought that code was changed
> > > so we only put the pointer to a pcb on the stack.
> >
> > pcb is on top of the stack,
On Mon, Dec 11, 2017 at 07:09:10AM -0800, Rodney W. Grimes wrote:
> [ Charset UTF-8 unsupported, converting... ]
> > New Revision: 326758
> > URL: https://svnweb.freebsd.org/changeset/base/326758
> >
> > Log:
> > i386: Bump KSTACK_PAGES default to match amd64
> >
> > Logically, extend r2862
> On Mon, Dec 11, 2017 at 07:09:10AM -0800, Rodney W. Grimes wrote:
> > The current comment about a pcb, I thought that code was changed
> > so we only put the pointer to a pcb on the stack.
>
> pcb is on top of the stack, followed by the userspace FPU registers save
> area. I do not see any sens
On Mon, Dec 11, 2017 at 07:09:10AM -0800, Rodney W. Grimes wrote:
> The current comment about a pcb, I thought that code was changed
> so we only put the pointer to a pcb on the stack.
pcb is on top of the stack, followed by the userspace FPU registers save
area. I do not see any sense in existen
[ Charset UTF-8 unsupported, converting... ]
> Author: cem
> Date: Mon Dec 11 04:32:37 2017
> New Revision: 326758
> URL: https://svnweb.freebsd.org/changeset/base/326758
>
> Log:
> i386: Bump KSTACK_PAGES default to match amd64
>
> Logically, extend r286288 to cover all threads, by default
On Mon, Dec 11, 2017 at 06:03:36PM +0700, Eugene Grosbein wrote:
> I do not try to contradict other usage patterns. In fact, I'm eager to know
> a practical example of such pattern: a task, an application, anything real?
Plain workstation use, like X11+browser+editor+some other programs easily
allo
On 11.12.2017 17:52, Konstantin Belousov wrote:
>> I still wonder if there is really such load pattern that creates "enough
>> threads"
>> for i386 to make 4-pages stack troublesome.
> Yes, there is such load pattern, it is when you do create threads. Your
> load, as described, is static. Peter'
On Mon, Dec 11, 2017 at 05:26:12PM +0700, Eugene Grosbein wrote:
> On 11.12.2017 16:19, Konstantin Belousov wrote:
> > On Mon, Dec 11, 2017 at 04:32:37AM +, Conrad Meyer wrote:
> >> Author: cem
> >> Date: Mon Dec 11 04:32:37 2017
> >> New Revision: 326758
> >> URL: https://svnweb.freebsd.org/ch
On 11.12.2017 16:19, Konstantin Belousov wrote:
> On Mon, Dec 11, 2017 at 04:32:37AM +, Conrad Meyer wrote:
>> Author: cem
>> Date: Mon Dec 11 04:32:37 2017
>> New Revision: 326758
>> URL: https://svnweb.freebsd.org/changeset/base/326758
>>
>> Log:
>> i386: Bump KSTACK_PAGES default to match
On Mon, Dec 11, 2017 at 04:32:37AM +, Conrad Meyer wrote:
> Author: cem
> Date: Mon Dec 11 04:32:37 2017
> New Revision: 326758
> URL: https://svnweb.freebsd.org/changeset/base/326758
>
> Log:
> i386: Bump KSTACK_PAGES default to match amd64
i386 is not amd64, the change is wrong.
i386 has
Author: cem
Date: Mon Dec 11 04:32:37 2017
New Revision: 326758
URL: https://svnweb.freebsd.org/changeset/base/326758
Log:
i386: Bump KSTACK_PAGES default to match amd64
Logically, extend r286288 to cover all threads, by default.
The world has largely moved on from i386. Most FreeBSD
56 matches
Mail list logo