Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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:

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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.

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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. >> >>

Re: svn commit: r326758 - in head/sys/i386: conf include

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.

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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: > >> > >>

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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. ___

Re: svn commit: r326758 - in head/sys/i386: conf include

> 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

Re: svn commit: r326758 - in head/sys/i386: conf include

[ 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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

> 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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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 >>>

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

[ 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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

> 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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

> 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

Re: svn commit: r326758 - in head/sys/i386: conf include

> 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

Re: svn commit: r326758 - in head/sys/i386: conf include

... > > > > 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

Re: svn commit: r326758 - in head/sys/i386: conf include

[ 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, > > > >

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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,

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

> 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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

[ 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

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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'

Re: svn commit: r326758 - in head/sys/i386: conf include

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:

Re: svn commit: r326758 - in head/sys/i386: conf include

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

Re: svn commit: r326758 - in head/sys/i386: conf include

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