Re: svn commit: r365249 - head

[Slawa Olhovchenkov]

On Wed, Sep 02, 2020 at 11:53:57AM -0400, Ryan Moeller wrote:

> 
> On 9/2/20 11:43 AM, Andriy Gapon wrote:
> > On 02/09/2020 18:23, Ryan Moeller wrote:
> >> On 9/2/20 10:28 AM, Warner Losh wrote:
> >>> Author: imp
> >>> Date: Wed Sep  2 14:28:54 2020
> >>> New Revision: 365249
> >>> URL: https://svnweb.freebsd.org/changeset/base/365249
> >>>
> >>> Log:
> >>>     Add note about needing to manually import the zfs pools or update
> >>>     /etc/rc.d due to the cache file moving to /etc.
> >>>
> >>> Modified:
> >>>     head/UPDATING
> >>>
> >>> Modified: head/UPDATING
> >>> ==
> >>> --- head/UPDATING    Wed Sep  2 12:57:34 2020    (r365248)
> >>> +++ head/UPDATING    Wed Sep  2 14:28:54 2020    (r365249)
> >>> @@ -36,6 +36,10 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW:
> >>>    scenarios have been tested and fixed, but rebuilding kernels 
> >>> without
> >>>    rebuilding world may fail.
> >>>    +    The ZFS cache file has moved from /boot to /etc to match the 
> >>> OpenZFS
> >>> +    upstream default. This means your zpool won't auto import until you
> >>> +    upgrade your /etc/rc.d files or you import them manually.
> >>> +
> >>>    20200824:
> >>>    The resume code now notifies devd with the 'kernel' system
> >>>    rather than the old 'kern' subsystem to be consistent with
> >> Thanks, enough people seemed to be getting tripped up by this.
> > I think that this is a very useful note.
> >
> > But I do not see a direct connection between the change of zpool.cache 
> > location
> > and the new ZFS's not automatically importing zpool.cache pools on boot.
> >
> 
> True, the real reason is that the kernel module in OpenZFS does not 
> autoimport pools.
> Instead we explicitly "zpool import -a" in one of the ZFS rc scripts. 

Is posible to restore old behavior?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r358995 - head/sys/net

[Slawa Olhovchenkov]

On Sat, Mar 14, 2020 at 07:43:44PM +, Patrick Kelsey wrote:

> Author: pkelsey
> Date: Sat Mar 14 19:43:44 2020
> New Revision: 358995
> URL: https://svnweb.freebsd.org/changeset/base/358995
> 
> Log:
>   Fix iflib freelist state corruption
>   
>   This fixes a bug in iflib freelist management that breaks the required
>   correspondence between freelist indexes and driver ring slots.
>   
>   PR: 243126, 243392, 240628

Are you sure?
Bug 240628 - sysutils/zfsnap2: Completion script link for zsh has
wrong path 

>   Reported by:avg, alexandr.oleyni...@gmail.com, Harald Schmalzbauer
>   Reviewed by:avg, gallatin
>   MFC after:  1 week
>   Differential Revision:  https://reviews.freebsd.org/D23943

Very interesting.
Is this related to my problem?
I am have trouble w/ netmap:

1. netmap reported RX slots filled all ring (tail == head-1)
2. application processed all RX slots and reported to nemap (head == tail)
3. RX stuck.

workaround: report on step 2 head = tail-1 (one RX slots left
unprocessed).

Also I am have trouble w/ TX, similar.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r358655 - head/sbin/mount_nfs

[Slawa Olhovchenkov]

On Thu, Mar 05, 2020 at 07:19:59PM +0100, Dimitry Andric wrote:

> On 5 Mar 2020, at 18:44, Gleb Smirnoff  wrote:
> > 
> > On Thu, Mar 05, 2020 at 08:35:15PM +0300, Slawa Olhovchenkov wrote:
> > S> > > D> sbin/mount_nfs/mount_nfs.c:549:10: error: cast from 'char *' to 
> > 'struct
> > S> > > D> if_msghdr *' increases required alignment from 1 to 4
> > S> > > D> [-Werror,-Wcast-align]
> > S> > > D> ifm = (struct if_msghdr *)buf;
> > S> > > D>   ^~~
> > S> > > D> 1 error generated.
> > S> > > D>
> > S> > > D> In practice I don't think the buffer can ever get misaligned, so 
> > can you
> > S> > > D> please add a NO_WCAST_ALIGN= to the Makefile?
> > S> > >
> > S> > > route(8) handles the same problem via intermediate (void *) cast. 
> > What is
> > S> > > preferred way to solve the problem? Change compiler flags file wide, 
> > or
> > S> > > just through (void *) cast?
> > S> >
> > S> > Copy to aligned buffer or got SIGBUS on some architectures?
> > S>
> > S> char buf[2048] __aligned(__alignof(struct if_msghdr));
> > S>
> > S> resolve this watning.
> > 
> > Thanks, Slawa! I think this is the most elegant solution.
> 
> Why don't just declare the buffer as:
> 
>   struct if_msghdr buf;
> 
> and then do:
> 
>   nread = read(s, , sizeof buf);
> 
> ?  You are never reading more than one if_msghdr anyway, and then there
> is no need to cast anything.

My inspiration: route socket can return other messages (man 4 route)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r358655 - head/sbin/mount_nfs

[Slawa Olhovchenkov]

On Thu, Mar 05, 2020 at 08:24:54PM +0300, Slawa Olhovchenkov wrote:

> On Thu, Mar 05, 2020 at 08:33:50AM -0800, Gleb Smirnoff wrote:
> 
> > On Thu, Mar 05, 2020 at 03:29:23PM +0100, Dimitry Andric wrote:
> > D> On 2020-03-04 23:27, Gleb Smirnoff wrote:
> > D> > Author: glebius
> > D> > Date: Wed Mar  4 22:27:16 2020
> > D> > New Revision: 358655
> > D> > URL: https://svnweb.freebsd.org/changeset/base/358655
> > D> > 
> > D> > Log:
> > D> >When a machine boots the NFS mounting script is executed after
> > D> >interfaces are configured, but for many interfaces (e.g. all Intel)
> > D> >ifconfig causes link renegotiation, so the first attempt to mount
> > D> >NFS always fails. After that mount_nfs sleeps for 30 seconds, while
> > D> >only a couple seconds are actually required for interface to get up.
> > D> >Instead of sleeping, do select(2) on routing socket and check if
> > D> >some interface became UP and in this case retry immediately.
> > D> 
> > D> At least on i386, this causes a -Werror warning:
> > D> 
> > D> sbin/mount_nfs/mount_nfs.c:549:10: error: cast from 'char *' to 'struct
> > D> if_msghdr *' increases required alignment from 1 to 4
> > D> [-Werror,-Wcast-align]
> > D> ifm = (struct if_msghdr *)buf;
> > D>   ^~~
> > D> 1 error generated.
> > D> 
> > D> In practice I don't think the buffer can ever get misaligned, so can you
> > D> please add a NO_WCAST_ALIGN= to the Makefile?
> > 
> > route(8) handles the same problem via intermediate (void *) cast. What is
> > preferred way to solve the problem? Change compiler flags file wide, or
> > just through (void *) cast?
> 
> Copy to aligned buffer or got SIGBUS on some architectures?

char buf[2048] __aligned(__alignof(struct if_msghdr));

resolve this watning.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r358655 - head/sbin/mount_nfs

[Slawa Olhovchenkov]

On Thu, Mar 05, 2020 at 08:33:50AM -0800, Gleb Smirnoff wrote:

> On Thu, Mar 05, 2020 at 03:29:23PM +0100, Dimitry Andric wrote:
> D> On 2020-03-04 23:27, Gleb Smirnoff wrote:
> D> > Author: glebius
> D> > Date: Wed Mar  4 22:27:16 2020
> D> > New Revision: 358655
> D> > URL: https://svnweb.freebsd.org/changeset/base/358655
> D> > 
> D> > Log:
> D> >When a machine boots the NFS mounting script is executed after
> D> >interfaces are configured, but for many interfaces (e.g. all Intel)
> D> >ifconfig causes link renegotiation, so the first attempt to mount
> D> >NFS always fails. After that mount_nfs sleeps for 30 seconds, while
> D> >only a couple seconds are actually required for interface to get up.
> D> >Instead of sleeping, do select(2) on routing socket and check if
> D> >some interface became UP and in this case retry immediately.
> D> 
> D> At least on i386, this causes a -Werror warning:
> D> 
> D> sbin/mount_nfs/mount_nfs.c:549:10: error: cast from 'char *' to 'struct
> D> if_msghdr *' increases required alignment from 1 to 4
> D> [-Werror,-Wcast-align]
> D> ifm = (struct if_msghdr *)buf;
> D>   ^~~
> D> 1 error generated.
> D> 
> D> In practice I don't think the buffer can ever get misaligned, so can you
> D> please add a NO_WCAST_ALIGN= to the Makefile?
> 
> route(8) handles the same problem via intermediate (void *) cast. What is
> preferred way to solve the problem? Change compiler flags file wide, or
> just through (void *) cast?

Copy to aligned buffer or got SIGBUS on some architectures?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r357849 - head/sys/cam/scsi

[Slawa Olhovchenkov]

On Thu, Feb 13, 2020 at 08:36:08AM -0700, Warner Losh wrote:

> On Thu, Feb 13, 2020 at 7:05 AM Slawa Olhovchenkov  wrote:
> 
> > On Thu, Feb 13, 2020 at 01:23:45AM +, Warner Losh wrote:
> >
> > > Author: imp
> > > Date: Thu Feb 13 01:23:44 2020
> > > New Revision: 357849
> > > URL: https://svnweb.freebsd.org/changeset/base/357849
> > >
> > > Log:
> > >   Convert rotating and unmapped_io to a DA flag
> > >
> > >   Rotating and unmapped_io are really da flags. Convert them to a flag
> > so it will
> > >   be reported with the other flags for the device. Deprecate the
> > .rotating and
> > >   .unmapped_io sysctls in FreeBSD 14 and remove the softc ints.
> >
> > Can you clarification this deprecate?
> >
> 
> The functionality has moved into the new .flags sysctl. I plan on keeping

Thanks!
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r357849 - head/sys/cam/scsi

[Slawa Olhovchenkov]

On Thu, Feb 13, 2020 at 01:23:45AM +, Warner Losh wrote:

> Author: imp
> Date: Thu Feb 13 01:23:44 2020
> New Revision: 357849
> URL: https://svnweb.freebsd.org/changeset/base/357849
> 
> Log:
>   Convert rotating and unmapped_io to a DA flag
>   
>   Rotating and unmapped_io are really da flags. Convert them to a flag so it 
> will
>   be reported with the other flags for the device. Deprecate the .rotating and
>   .unmapped_io sysctls in FreeBSD 14 and remove the softc ints.

Can you clarification this deprecate?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r357553 - head/sys/dev/cxgbe

[Slawa Olhovchenkov]

On Wed, Feb 05, 2020 at 12:13:15AM +, Navdeep Parhar wrote:

> Author: np
> Date: Wed Feb  5 00:13:15 2020
> New Revision: 357553
> URL: https://svnweb.freebsd.org/changeset/base/357553
> 
> Log:
>   cxgbe(4): Add a knob to allow netmap tx traffic to be checksummed by
>   the hardware.
>   
>   hw.cxgbe.nm_txcsum=1

Very interesting.
Please, describe some more detail about using this feture (for
example, set this before driver loading? first netmap open? any netmap
open? on the fly?)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Slawa Olhovchenkov]

On Fri, Jan 17, 2020 at 08:17:11PM +0700, Eugene Grosbein wrote:

>  Considering /usr/ports, /usr/src and /usr/obj and amount of RAM
>  needed to keep metadata in ZFS ARC
> >>>
> >>> /usr/ports, /usr/src and /usr/obj don't need be exist on low-RAM
> >>> install -- use poudriere and release build on dedicated build host and
> >>> applay binary update.
> >>
> >> Poudriere itself has its disadvantages. It's heavy and it's unable to 
> >> produce minimal set of target packages
> >> suitable for "pkg install -U *.txz" command without build-only 
> >> dependencies.
> > 
> > Can you do it by /usr/ports way? No. And what you point?
> 
> I can and I do, with my own scripts.
> 
> >> I'd like to stick with poudriere but could not. Its supposed work-style 
> >> does not worth it.
> >>
> >> Real Work (TM) sometimes presents the need to apply patches, so
> >> /usr/src and /usr/obj may become are unavoidable.
> > 
> > I am do w/ dedicated builhost, produce custom build of
> > base.txz/kernel.txz/kernel.CUSTOM.txz and applay binary updates w/ BE.
> > What you point?
> 
> The virtual guest is stand-alone including upgrades, does not depend on build 
> host nor its existance.
> 
> >> 1GB-RAM UFS system runs just fine with such trees being stand-alone and 
> >> does not require extra build system and nor its overhead.
> > 
> > clang very hard to compile in 1GB RAM.
> 
> It was fine before clang-[78]. Buy nowadays, yes, I'm forced to use multiple 
> knobs for src.conf
> 
> WITHOUT_LLVM_TARGET_ALL=
> WITH_LLVM_TARGET_X86=
> WITHOUT_CLANG_FULL=
> 
> And using WITH_META_MODE not cleaning obj directory.
> 
> > Anyway, my 1GB ZFS system run just fine.
> 
> During life-time of stable/10 and early stable/11 (and not so-early)
> ZFS required hard tuning for 1GB i386 system to be stable because it's 
> KVM-hog.

I am cleary understund you provide expirence from satble/10 to
current/13?
w/ different clang, kernel, etc?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Slawa Olhovchenkov]

On Fri, Jan 17, 2020 at 07:35:02PM +0700, Eugene Grosbein wrote:

> 17.01.2020 18:21, Slawa Olhovchenkov wrote:
> 
> >> Considering /usr/ports, /usr/src and /usr/obj and amount of RAM
> >> needed to keep metadata in ZFS ARC
> > 
> > /usr/ports, /usr/src and /usr/obj don't need be exist on low-RAM
> > install -- use poudriere and release build on dedicated build host and
> > applay binary update.
> 
> Poudriere itself has its disadvantages. It's heavy and it's unable to produce 
> minimal set of target packages
> suitable for "pkg install -U *.txz" command without build-only dependencies.

Can you do it by /usr/ports way? No. And what you point?

> I'd like to stick with poudriere but could not. Its supposed work-style does 
> not worth it.
> 
> Real Work (TM) sometimes presents the need to apply patches, so
> /usr/src and /usr/obj may become are unavoidable.

I am do w/ dedicated builhost, produce custom build of
base.txz/kernel.txz/kernel.CUSTOM.txz and applay binary updates w/ BE.
What you point?

> 1GB-RAM UFS system runs just fine with such trees being stand-alone and does 
> not require extra build system and nor its overhead.

clang very hard to compile in 1GB RAM.
Anyway, my 1GB ZFS system run just fine.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Slawa Olhovchenkov]

On Thu, Jan 16, 2020 at 04:19:52PM -0800, Devin Teske wrote:

> 
> 
> > On Jan 16, 2020, at 16:03, Slawa Olhovchenkov  wrote:
> > 
> > On Thu, Jan 16, 2020 at 02:43:37PM +0700, Eugene Grosbein wrote:
> > 
> >> 16.01.2020 4:41, Ed Maste wrote:
> >> 
> >>> On Wed, 15 Jan 2020 at 16:10, Eugene Grosbein  wrote:
> >>>> 
> >>>> There are multiple scenarios there ZFS may be sub-optimal at least: 
> >>>> small i386 virtual guests
> >>>> or 32-bit only hardware like AMD Geode, or big amd64 SSD-only systems 
> >>>> with bhyve and multiple guests
> >>>> that need lots of memory and should not fight with ZFS for RAM etc.
> >>> 
> >>> That may well be the case, but our defaults should represent the
> >>> configuration that's desirable to the largest set of users, and IMO
> >>> that's ZFS in most cases today.
> >>> 
> >>> It might be that we should default to UFS on i386 and ZFS on amd64?
> >> 
> >> UFS may be better for any virtual guest having RAM less or equal to 4GB.
> > 
> > Why?
> 
> ZFS does not do any auto-tuning in that situation and you’ll quickly
> find you’ll have a dozen or more tunables in loader.conf tailored to
> your workload. Even moderate workloads require tuning in i386 and/or
> <=4GB environments with ZFS.

This (auto-tuning) can be fixed, I am do this.

> It is also highly inadvisable to mix UFS and ZFS — memory pressure from ARC 
> can cause UFS cache evictions and vice-versa.

May be, don't test
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Slawa Olhovchenkov]

On Fri, Jan 17, 2020 at 12:12:22PM +0700, Eugene Grosbein wrote:

> 17.01.2020 7:03, Slawa Olhovchenkov write:
> 
> >>>> There are multiple scenarios there ZFS may be sub-optimal at least: 
> >>>> small i386 virtual guests
> >>>> or 32-bit only hardware like AMD Geode, or big amd64 SSD-only systems 
> >>>> with bhyve and multiple guests
> >>>> that need lots of memory and should not fight with ZFS for RAM etc.
> >>>
> >>> That may well be the case, but our defaults should represent the
> >>> configuration that's desirable to the largest set of users, and IMO
> >>> that's ZFS in most cases today.
> >>>
> >>> It might be that we should default to UFS on i386 and ZFS on amd64?
> >>
> >> UFS may be better for any virtual guest having RAM less or equal to 4GB.
> > 
> > Why?
> 
> Considering /usr/ports, /usr/src and /usr/obj and amount of RAM
> needed to keep metadata in ZFS ARC

/usr/ports, /usr/src and /usr/obj don't need be exist on low-RAM
install -- use poudriere and release build on dedicated build host and
applay binary update.

> plus standard daily periodic scripts traveling filesystems, low-RAM virtual 
> machine utilizing its RAM to full amount
> can work reliably with UFS and hang at nights due to extra ZFS overhead in 
> default install (not tuned).

Just need fix ZFS ARC pressure and UMA zone reclaim.
ZFS ARC overhead about 10-20MB (IMHO) on low-RAM install. This is
negligible from 512MB.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r356758 - in head/usr.sbin/bsdinstall: . scripts

[Slawa Olhovchenkov]

On Thu, Jan 16, 2020 at 02:43:37PM +0700, Eugene Grosbein wrote:

> 16.01.2020 4:41, Ed Maste wrote:
> 
> > On Wed, 15 Jan 2020 at 16:10, Eugene Grosbein  wrote:
> >>
> >> There are multiple scenarios there ZFS may be sub-optimal at least: small 
> >> i386 virtual guests
> >> or 32-bit only hardware like AMD Geode, or big amd64 SSD-only systems with 
> >> bhyve and multiple guests
> >> that need lots of memory and should not fight with ZFS for RAM etc.
> > 
> > That may well be the case, but our defaults should represent the
> > configuration that's desirable to the largest set of users, and IMO
> > that's ZFS in most cases today.
> > 
> > It might be that we should default to UFS on i386 and ZFS on amd64?
> 
> UFS may be better for any virtual guest having RAM less or equal to 4GB.

Why?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r352868 - in head/sys/netinet: . tcp_stacks

[Slawa Olhovchenkov]

On Sun, Sep 29, 2019 at 10:45:13AM +, Michael Tuexen wrote:

> Author: tuexen
> Date: Sun Sep 29 10:45:13 2019
> New Revision: 352868
> URL: https://svnweb.freebsd.org/changeset/base/352868
> 
> Log:
>   RFC 7112 requires a host to put the complete IP header chain
>   including the TCP header in the first IP packet.
>   Enforce this in tcp_output(). In addition make sure that at least
>   one byte payload fits in the TCP segement to allow making progress.
>   Without this check, a kernel with INVARIANTS will panic.
>   This issue was found by running an instance of syzkaller.

How to posible this?
Host required to handle packets up to 576 bytes, how to IP and TCP
options can exhaust this size?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r351673 - in head: lib/libmemstat share/man/man9 sys/cddl/compat/opensolaris/kern sys/kern sys/vm

[Slawa Olhovchenkov]

On Sun, Sep 08, 2019 at 04:18:19PM -0400, Mark Johnston wrote:

> On Sat, Sep 07, 2019 at 06:31:10PM +0300, Slawa Olhovchenkov wrote:
> > On Sat, Sep 07, 2019 at 10:50:34AM -0400, Mark Johnston wrote:
> > 
> > > On Wed, Sep 04, 2019 at 05:45:24PM +0300, Slawa Olhovchenkov wrote:
> > > > On Tue, Sep 03, 2019 at 06:01:06PM -0400, Mark Johnston wrote:
> > > > > > Mostly problem I am see at this
> > > > > > work -- very slowly vm_page_free(). May be currenly this is more
> > > > > > speedy...
> > > > > 
> > > > > How did you determine this?
> > > > 
> > > > This is you guess:
> > > 
> > > So was the guess correct?
> > 
> > I am just trust to you.
> > How to check this guess?
> 
> You can try to measure time spent in pmap_remove() relative to the rest
> of _kmem_unback().

===
fbt:kernel:_kmem_unback:entry {   self->kts = timestamp; }
fbt:kernel:_kmem_unback:return /self->kts/{  @ts["kts"] = sum(timestamp - 
self->kts);  self->kts = 0; }
fbt:kernel:pmap_remove:entry   /self->kts/{  self->pts = timestamp; }
fbt:kernel:pmap_remove:entry  /self->kts == 0/ { self->ats = timestamp; }
fbt:kernel:pmap_remove:return /self->pts/ {  @ts["pts"] = sum(timestamp - 
self->pts); self->pts = 0; }
fbt:kernel:pmap_remove:return /self->ats/ {  @ts["ats"] = sum(timestamp - 
self->ats); self->ats = 0; }

tick-1s
{
  printa("%-8s %20@d\n", @ts);
  printf("\n");
  clear(@ts);
}
===

pts   7166680
ats   8143193
kts  16721822

pts   3458647
ats   5393452
kts  10504523

kts 0
pts 0
ats   2758752

pts   3387748
ats   4322653
kts   8100282

pts   4002444
ats   5422748
kts  11761955

pts   1151713
kts   2742176
ats   8242958

pts 34441
kts145683
ats   4822328

kts 0
pts 0
ats   5357808

pts 16008
kts148203
ats   4947368

pts 26945
kts156011
ats   8368502

pts323620
kts   1154981
ats  10093137

pts 79504
kts228135
ats   7131059

pts734062
kts   1747364
ats   4619796

pts401453
kts   1036605
ats   8751919

> > > If so, IMO the real solution is to avoid kmem_*
> > > for data buffers and use ABD instead.
> > 
> > What problem resolve this?
> 
> To allocate buffers larger than PAGE_SIZE the kernel must allocate a
> number of physical pages and map them using the page tables.  The step
> of creating and destroying mappings is expensive and doesn't scale well
> to many CPUs.  With ABD, ZFS avoids this expense when its caches are
> shrunk.
> 
> > ABD any way is slowly vs kmem_*.
> 
> Can we solve this problem instead?

slowly ABD? or expensive of creating and destroying mappings?
slowly ABD -- don't use ABD and scatter gather.
expensive of creating and destroying mappings:

- do kernel more NUMA-aware and go mostly alloc and free to zone cache
  (curenly may be allocation can do from dom1 and freeing in dom0. I am see 
this.)
- calculate sensible working set size of zone cache and aim trim to do nothing
- my be do batch removed/unmaped and do TLB shootdown only once at end of batch?

> > > > ==
> > > > > while ((slab = SLIST_FIRST()) != NULL) {
> > > > > SLIST_REMOVE(, slab, uma_slab, us_hlink);
> > > > > keg_free_slab(keg, slab, keg->uk_ipers);
> > > > > }
> > > > > 2019 Feb  2 19:49:54.800524364   zio_data_buf_1048576  1032605 
> > > > > cache_reclaim limit  100 dom 0 nitems 1672 imin  298
> > > > > 2019 Feb  2 19:49:54.800524364   zio_data_buf_1048576  1033736 
> > > > > cache_reclaim recla  149 dom 0 nitems 1672 imin  298
> > > > > 2019 Feb  2 19:49:54.802524468   zio_data_buf_1048576  3119710 
> > > > > cache_reclaim limit  100 dom 1 nitems1 imin0
> > > > > 2019 Feb  2 19:49:54.802524468   zio_data_buf_1048576  3127550 
> > > > > keg_dr

Re: svn commit: r351673 - in head: lib/libmemstat share/man/man9 sys/cddl/compat/opensolaris/kern sys/kern sys/vm

[Slawa Olhovchenkov]

On Sat, Sep 07, 2019 at 10:50:34AM -0400, Mark Johnston wrote:

> On Wed, Sep 04, 2019 at 05:45:24PM +0300, Slawa Olhovchenkov wrote:
> > On Tue, Sep 03, 2019 at 06:01:06PM -0400, Mark Johnston wrote:
> > > > Mostly problem I am see at this
> > > > work -- very slowly vm_page_free(). May be currenly this is more
> > > > speedy...
> > > 
> > > How did you determine this?
> > 
> > This is you guess:
> 
> So was the guess correct?

I am just trust to you.
How to check this guess?

> If so, IMO the real solution is to avoid kmem_*
> for data buffers and use ABD instead.

What problem resolve this?
ABD any way is slowly vs kmem_*.

> > ==
> > > while ((slab = SLIST_FIRST()) != NULL) {
> > > SLIST_REMOVE(, slab, uma_slab, us_hlink);
> > > keg_free_slab(keg, slab, keg->uk_ipers);
> > > }
> > > 2019 Feb  2 19:49:54.800524364   zio_data_buf_1048576  1032605 
> > > cache_reclaim limit  100 dom 0 nitems 1672 imin  298
> > > 2019 Feb  2 19:49:54.800524364   zio_data_buf_1048576  1033736 
> > > cache_reclaim recla  149 dom 0 nitems 1672 imin  298
> > > 2019 Feb  2 19:49:54.802524468   zio_data_buf_1048576  3119710 
> > > cache_reclaim limit  100 dom 1 nitems1 imin0
> > > 2019 Feb  2 19:49:54.802524468   zio_data_buf_1048576  3127550 
> > > keg_drain2
> > > 2019 Feb  2 19:49:54.803524487   zio_data_buf_1048576  219 
> > > keg_drain3
> > > 2019 Feb  2 19:49:54.838524634   zio_data_buf_1048576 39553705 
> > > keg_drain4
> > > 2019 Feb  2 19:49:54.838524634   zio_data_buf_1048576 39565323 
> > > zone_reclaim:return
> > >
> > > 35109.486 ms for last loop, 149 items to freed.
> > 
> > 35ms to free 149MB (38144 4KB pages), so roughly 1us per page.  That
> > does seem like a lot, but freeing a page (vm_page_free(m)) is much
> > more expensive than freeing an item to UMA (i.e., uma_zfree()).
> > Most of that time will be spent in _kmem_unback().
> > ==
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r351673 - in head: lib/libmemstat share/man/man9 sys/cddl/compat/opensolaris/kern sys/kern sys/vm

[Slawa Olhovchenkov]

On Wed, Sep 04, 2019 at 09:27:00AM +0300, Andriy Gapon wrote:

> On 04/09/2019 01:01, Mark Johnston wrote:
> > Some of the vm_lowmem eventhandlers probably shouldn't be called each
> > time the page daemon scans the inactive queue (every 0.1s under memory
> > pressure).  ufsdirhash_lowmem and mb_reclaim in particular don't seem
> > like they need to be invoked very frequently.  We could easily define
> > multiple eventhandlers to differentiate between these cases, though.
> 
> My proposal is to run uma_reclaim(UMA_RECLAIM_TRIM) before invoking vm_lowmem.
> If that reclaims "enough" memory, then do not call vm_lowmem at all.
> 
> Oh, and I have a related question.
> Say, a zone has X items in use and Y items in cache.
> After running vm_lowmem the composition changes to X - C and Y + C 
> respectively.
> Then we run uma_reclaim(UMA_RECLAIM_TRIM).
> Question: is that guaranteed to free at least C items?
> I am thinking about a possibility that the zone's workset size is estimated to
> be at least X (and maybe even more than X + Y).  In that case UMA_RECLAIM_TRIM
> won't free those C items, they will stay in the cache.  So, it seems like
> releasing them was in vain, at least for the immediate reclaim.

My goal is uma_reclaim(UMA_RECLAIM_TRIM) reclaim from zone cache up to zone 
cache working set.
Idealy in stable run uma_reclaim(UMA_RECLAIM_TRIM) do nothing and all
allocation/free from zone go from/to zone cache. As result
uma_reclaim(UMA_RECLAIM_TRIM) work only for rebalance memory consume at
working profile change.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r351673 - in head: lib/libmemstat share/man/man9 sys/cddl/compat/opensolaris/kern sys/kern sys/vm

[Slawa Olhovchenkov]

On Tue, Sep 03, 2019 at 06:01:06PM -0400, Mark Johnston wrote:

> > > have you considered running UMA_RECLAIM_TRIM periodically, even without a 
> > > memory
> > > pressure?
> > > I think that with such a periodic trimming there will be less need to 
> > > invoke
> > > vm_lowmem().
> 
> Slawa and I talked about this in the past.  His complaint is that a
> large cache can take a significant amount of time to trim, and it

Not only large cache. Also I am see large mbuf cache (10GB+ after pike network 
activites)
and many other zones. For example, live server w/ stable/11, cache sizes of 
zones in MB:

54 RADIX NODE
55 zio_data_buf_131072
73 zio_data_buf_12288
77 zio_data_buf_98304
93 socket
99 tcpcb
  1072 mbuf
  1136 zio_buf_131072
  1443 zio_data_buf_1048576
 17242 mbuf_jumbo_page

> manifests as a spike of CPU usage and contention on the zone lock.  In
> particular, keg_drain() iterates over the list of free slabs with the
> keg lock held, and if the many items were freed to the keg while
> trimming/draining, the list can be quite long.  This can have effects
> outside the zone, for example if we are reclaiming items from zones used
> by other UMA zones, like the bucket or slab zones.
> 
> Reclaiming cached items when there is no demand for free pages seems
> wrong to me.  We historically had similar problems with the page daemon,
> which last year was changed to perform smaller reclamations at a greater
> frequency.  I suspect a better approach for UMA would be to similarly
> increase reclaim frequency and reduce the number of items freed in one
> go.

My goal is next:

1. Today memory size is quite big. 64GB is minimal, 256GB is not extraordinary.
   As result memory processed at lowmem event can be very big compared to 
historicaly.
2. Memory reclaiming is very expensetive at last stage. As result reclaiming 
some 10GB
   can take 10s and more
3. Memory depletion may be very fast at current speed (40Gbit network 
connectivity is 5GB/s).
   As result (2+3) memory reclaiming at lowmem event may be slow for depletion 
compensation.
4. Many susbsystem now try do't cause lowmem by automatic memory depletion. 
Large unused in
   zone cache memory cause inefficent memory use (see above -- about 18GB 
memory may be used
   as cache or other way but currently just in zone cache. lowmem don't caused 
because all consumer
   try to rest sufficient free memory)
5. NUMA dramatize situation because (as I see) memory allocation can give from 
dom1 and free to dom0.
   As result zone cache in dom0 rise and don't used. Currently kernel not fully 
NUMA-avare and need many work.
6. All of this can cause exause memory below vmd_free_reserved and slowly many 
operation in kernel.

I am see all of this.

> > > Also, I think that we would be able to retire (or re-purpose) 
> > > lowmem_period.
> > > E.g., the trimming would be done every lowmem_period, but vm_lowmem() 
> > > would not
> > > be throttled.
> 
> Some of the vm_lowmem eventhandlers probably shouldn't be called each
> time the page daemon scans the inactive queue (every 0.1s under memory
> pressure).  ufsdirhash_lowmem and mb_reclaim in particular don't seem
> like they need to be invoked very frequently.  We could easily define
> multiple eventhandlers to differentiate between these cases, though.
> 
> > > One example of the throttling of vm_lowmem being bad is its interaction 
> > > with the
> > > ZFS ARC.  When there is a spike in memory usage we want the ARC to adapt 
> > > as
> > > quickly as possible.  But at present the lowmem_period logic interferes 
> > > with that.
> >
> > Some time ago, I sent Mark a patch that implements this logic,
> > specialy for ARC and mbuf cooperate.
> >
> > Mostly problem I am see at this
> > work -- very slowly vm_page_free(). May be currenly this is more
> > speedy...
> 
> How did you determine this?

This is you guess:

==
> while ((slab = SLIST_FIRST()) != NULL) {
> SLIST_REMOVE(, slab, uma_slab, us_hlink);
> keg_free_slab(keg, slab, keg->uk_ipers);
> }
> 2019 Feb  2 19:49:54.800524364   zio_data_buf_1048576  1032605 
> cache_reclaim limit  100 dom 0 nitems 1672 imin  298
> 2019 Feb  2 19:49:54.800524364   zio_data_buf_1048576  1033736 
> cache_reclaim recla  149 dom 0 nitems 1672 imin  298
> 2019 Feb  2 19:49:54.802524468   zio_data_buf_1048576  3119710 
> cache_reclaim limit  100 dom 1 nitems1 imin0
> 2019 Feb  2 19:49:54.802524468   zio_data_buf_1048576  3127550 keg_drain2
> 2019 Feb  2 19:49:54.803524487   zio_data_buf_1048576  219 keg_drain3
> 2019 Feb  2 19:49:54.838524634   zio_data_buf_1048576 39553705 keg_drain4
> 2019 Feb  2 19:49:54.838524634   zio_data_buf_1048576 39565323 
> zone_reclaim:return
>
> 35109.486 ms for last loop, 149 items to freed.

35ms to free 149MB (38144 4KB pages), so roughly 1us per page.  That
does seem like a lot, but freeing a page 

Re: svn commit: r351673 - in head: lib/libmemstat share/man/man9 sys/cddl/compat/opensolaris/kern sys/kern sys/vm

[Slawa Olhovchenkov]

On Tue, Sep 03, 2019 at 10:02:59AM +0300, Andriy Gapon wrote:

> On 02/09/2019 01:22, Mark Johnston wrote:
> > Author: markj
> > Date: Sun Sep  1 22:22:43 2019
> > New Revision: 351673
> > URL: https://svnweb.freebsd.org/changeset/base/351673
> > 
> > Log:
> >   Extend uma_reclaim() to permit different reclamation targets.
> >   
> >   The page daemon periodically invokes uma_reclaim() to reclaim cached
> >   items from each zone when the system is under memory pressure.  This
> >   is important since the size of these caches is unbounded by default.
> >   However it also results in bursts of high latency when allocating from
> >   heavily used zones as threads miss in the per-CPU caches and must
> >   access the keg in order to allocate new items.
> >   
> >   With r340405 we maintain an estimate of each zone's usage of its
> >   (per-NUMA domain) cache of full buckets.  Start making use of this
> >   estimate to avoid reclaiming the entire cache when under memory
> >   pressure.  In particular, introduce TRIM, DRAIN and DRAIN_CPU
> >   verbs for uma_reclaim() and uma_zone_reclaim().  When trimming, only
> >   items in excess of the estimate are reclaimed.  Draining a zone
> >   reclaims all of the cached full buckets (the previous behaviour of
> >   uma_reclaim()), and may further drain the per-CPU caches in extreme
> >   cases.
> >   
> >   Now, when under memory pressure, the page daemon will trim zones
> >   rather than draining them.  As a result, heavily used zones do not incur
> >   bursts of bucket cache misses following reclamation, but large, unused
> >   caches will be reclaimed as before.
> 
> Mark,
> 
> have you considered running UMA_RECLAIM_TRIM periodically, even without a 
> memory
> pressure?
> I think that with such a periodic trimming there will be less need to invoke
> vm_lowmem().
> 
> Also, I think that we would be able to retire (or re-purpose) lowmem_period.
> E.g., the trimming would be done every lowmem_period, but vm_lowmem() would 
> not
> be throttled.
> 
> One example of the throttling of vm_lowmem being bad is its interaction with 
> the
> ZFS ARC.  When there is a spike in memory usage we want the ARC to adapt as
> quickly as possible.  But at present the lowmem_period logic interferes with 
> that.

Some time ago, I sent Mark a patch that implements this logic,
specialy for ARC and mbuf cooperate. Mostly problem I am see at this
work -- very slowly vm_page_free(). May be currenly this is more
speedy...
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r350402 - stable/11/cddl/contrib/opensolaris/lib/libzfs/common

[Slawa Olhovchenkov]

On Mon, Jul 29, 2019 at 08:23:15AM +, Baptiste Daroussin wrote:

still broken:

# ls -l /poudriere/ports/default
ls: /poudriere/ports/default: No such file or directory

# zfs list
NAME USED  AVAIL  REFER  MOUNTPOINT
DB   256G   643G96K  /DB
DB/var   255G   643G96K  /DB/var
DB/var/db255G   643G96K  /DB/var/db
DB/var/db/mysql  255G   643G   255G  /var/db/mysql
DB/var/db/mysql/MyISAM96K   643G96K  /var/db/mysql/MyISAM
DB/var/db/mysql/innodb-logs  128M   643G   128M  /var/db/mysql/innodb-logs
zroot   2.94T   551G   112K  /ZROOT
zroot/ROOT   352M   551G   352M  /
zroot/home   144K   551G   144K  legacy
zroot/poudriere 5.41G   551G   128K  /poudriere
zroot/poudriere/data 608M   551G   608M  /poudriere/data
zroot/poudriere/jails   2.71G   551G   128K  /poudriere/jails
zroot/poudriere/jails/10amd64   2.71G   551G  2.71G  /poudriere/jails/10amd64
zroot/poudriere/ports   2.10G   551G96K  /poudriere/ports
zroot/poudriere/ports/default   2.10G   551G  2.10G  /poudriere/ports/default
zroot/tmp   6.94G   551G  6.94G  /tmp
zroot/usr630G   551G  57.0G  /usr
zroot/usr/local  543G   551G   543G  /usr/local
zroot/usr/obj   19.2G   551G  19.2G  /usr/obj
zroot/usr/ports 4.80G   551G  1.07G  /usr/ports
zroot/usr/ports/distfiles   3.72G   551G  3.72G  /usr/ports/distfiles
zroot/usr/ports/packages7.04M   551G  7.04M  /usr/ports/packages
zroot/usr/src   5.51G   551G  5.51G  /usr/src
zroot/var345G   551G  1.10G  /var
zroot/var/crash  148K   551G   148K  /var/crash
zroot/var/db58.4G   551G  3.92G  /var/db
zroot/var/db/mysql  54.4G   551G  54.2G  /var/db/mysql
zroot/var/db/mysql/MyISAM144K   551G   144K  /var/db/mysql/MyISAM
zroot/var/db/mysql/innodb-logs   128M   551G   128M  /var/db/mysql/innodb-logs
zroot/var/db/pkg69.6M   551G  69.6M  /var/db/pkg
zroot/var/empty  144K   551G   144K  /var/empty
zroot/var/log248G   551G   248G  /var/log
zroot/var/mail   148K   551G   148K  /var/mail
zroot/var/run444K   551G   444K  /var/run
zroot/var/spool 37.3G   551G  37.3G  /var/spool
zroot/var/tmp548K   551G   548K  /var/tmp
zroot/www   1.98T   551G   160K  /www
zroot/www/dev0  1.59G   551G  1.59G  /www/dev0
zroot/www/dev1  1.48G   551G  1.48G  /www/dev1
zroot/www/dev2  1.48G   551G  1.48G  /www/dev2
zroot/www/dev3  1.59G   551G  1.59G  /www/dev3
zroot/www/dev4  1.49G   551G  1.49G  /www/dev4
zroot/www/dev5  1.47G   551G  1.47G  /www/dev5
zroot/www/komandirovka   186G   551G  30.9G  /www/komandirovka
zroot/www/komandirovka_old  1.79T   551G  1.79T  /www/komandirovka_old


> Author: bapt
> Date: Mon Jul 29 08:23:15 2019
> New Revision: 350402
> URL: https://svnweb.freebsd.org/changeset/base/350402
> 
> Log:
>   MFC r350358:
>   
>   Fix a bug introduced with parallel mounting of zfs
>   
>   Incorporate a fix from zol:
>   
> https://github.com/zfsonlinux/zfs/commit/ab5036df1ccbe1b18c1ce6160b5829e8039d94ce
>   
>   commit log from upstream:
>Fix race in parallel mount's thread dispatching algorithm
>   
>   Strategy of parallel mount is as follows.
>   
>   1) Initial thread dispatching is to select sets of mount points that
>don't have dependencies on other sets, hence threads can/should run
>lock-less and shouldn't race with other threads for other sets. Each
>thread dispatched corresponds to top level directory which may or may
>not have datasets to be mounted on sub directories.
>   
>   2) Subsequent recursive thread dispatching for each thread from 1)
>is to mount datasets for each set of mount points. The mount points
>within each set have dependencies (i.e. child directories), so child
>directories are processed only after parent directory completes.
>   
>   The problem is that the initial thread dispatching in
>   zfs_foreach_mountpoint() can be multi-threaded when it needs to be
>   single-threaded, and this puts threads under race condition. This race
>   appeared as mount/unmount issues on ZoL for ZoL having different
>   timing regarding mount(2) execution due to fork(2)/exec(2) of mount(8).
>   `zfs unmount -a` which expects proper mount order can't unmount if the
>   mounts were reordered by the race condition.
>   
>   There are currently two known patterns of input list `handles` in
>   `zfs_foreach_mountpoint(..,handles,..)` which cause the race condition.
>   
>   1) #8833 case where 

Re: svn commit: r348772 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Slawa Olhovchenkov]

On Fri, Jun 07, 2019 at 06:35:42AM +, Andriy Gapon wrote:

> Author: avg
> Date: Fri Jun  7 06:35:42 2019
> New Revision: 348772
> URL: https://svnweb.freebsd.org/changeset/base/348772
> 
> Log:
>   Restore ARC MFU/MRU pressure
>   
>   Before r305323 (MFV r302991: 6950 ARC should cache compressed data)
>   arc_read() code did this for access to a ghost buffer:
>arc_adapt() (from arc_get_data_buf())
>arc_access(hdr, hash_lock)
>   I.e., we first checked access to the MFU ghost/MRU ghost buffer and
>   adapt MFU/MRU sizes (in arc_adapt()) and next move buffer from the ghost
>   state to regular.
>   
>   After r305323 the sequence is different:
>arc_access(hdr, hash_lock);
>arc_hdr_alloc_pabd(hdr);
>   I.e., we first move the buffer from the ghost state in arc_access() and
>   then we check access to buffer in ghost state (in arc_hdr_alloc_pabd()
>   -> arc_get_data_abd() -> arc_get_data_impl() -> arc_adapt()).  This is
>   incorrect: arc_adapt() never see access to the ghost buffer because
>   arc_access() already migrated the buffer from the ghost state to
>   regular.
>   
>   So, the fix is to restore a call to arc_adapt() before arc_access() and
>   to suppress the call to arc_adapt() after arc_access().
>   
>   Submitted by:   Slawa Olhovchenkov 
>   MFC after:  2 weeks
>   Sponsored by:   Integros [integros.com]
>   Differential Revision: https://reviews.freebsd.org/D19094

Include in 11.3-RELEASE planed?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r348117 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Slawa Olhovchenkov]

On Wed, May 22, 2019 at 04:00:58PM -0400, Alexander Motin wrote:

> On 22.05.2019 15:49, Slawa Olhovchenkov wrote:
> > On Wed, May 22, 2019 at 06:43:48PM +, Alexander Motin wrote:
> >> Author: mav
> >> Date: Wed May 22 18:43:48 2019
> >> New Revision: 348117
> >> URL: https://svnweb.freebsd.org/changeset/base/348117
> >>
> >> Log:
> >>   Allocate buffers smaller then ABD chunk size as linear.
> >>   
> >>   This allows to reduce memory waste by letting UMA to put multiple small
> >>   buffers into one memory page slab.  The page sharing means that UMA
> >>   may not be able to free memory page when some of buffers are freed, but
> >>   alternatively memory used by that buffer would just be wasted from the
> >>   beginning.
> >>   
> >>   This change follows alike change in ZoL, but unlike Linux (according to
> >>   my understanding of it from comments) FreeBSD never shares slabs bigger
> >>   then one memory page, so this should be even less invasive then there.
> >>   
> >>   MFC after:   2 weeks
> >>   Sponsored by:iXsystems, Inc.
> >>
> >> Modified:
> >>   head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/abd.c
> >>
> >> Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/abd.c
> >> ==
> >> --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/abd.c  Wed May 
> >> 22 17:42:22 2019(r348116)
> >> +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/abd.c  Wed May 
> >> 22 18:43:48 2019(r348117)
> >> @@ -290,7 +290,7 @@ abd_free_struct(abd_t *abd)
> >>  abd_t *
> >>  abd_alloc(size_t size, boolean_t is_metadata)
> >>  {
> >> -  if (!zfs_abd_scatter_enabled)
> >> +  if (!zfs_abd_scatter_enabled || size <= zfs_abd_chunk_size)
> >>return (abd_alloc_linear(size, is_metadata));
> > 
> > may be `size < zfs_abd_chunk_size`?
> 
> Why?  It should be the same from memory usage, but I see theoretical
> benefits from having linear buffer with one page rather then scatter
> list with one page.  Plus ZoL also had there `size <= PAGESIZE`.

May be malloc() for page size more effictive? Not sure.
Less overhead for kegs and etc.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r348117 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Slawa Olhovchenkov]

On Wed, May 22, 2019 at 06:43:48PM +, Alexander Motin wrote:

> Author: mav
> Date: Wed May 22 18:43:48 2019
> New Revision: 348117
> URL: https://svnweb.freebsd.org/changeset/base/348117
> 
> Log:
>   Allocate buffers smaller then ABD chunk size as linear.
>   
>   This allows to reduce memory waste by letting UMA to put multiple small
>   buffers into one memory page slab.  The page sharing means that UMA
>   may not be able to free memory page when some of buffers are freed, but
>   alternatively memory used by that buffer would just be wasted from the
>   beginning.
>   
>   This change follows alike change in ZoL, but unlike Linux (according to
>   my understanding of it from comments) FreeBSD never shares slabs bigger
>   then one memory page, so this should be even less invasive then there.
>   
>   MFC after:  2 weeks
>   Sponsored by:   iXsystems, Inc.
> 
> Modified:
>   head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/abd.c
> 
> Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/abd.c
> ==
> --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/abd.c Wed May 22 
> 17:42:22 2019(r348116)
> +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/abd.c Wed May 22 
> 18:43:48 2019(r348117)
> @@ -290,7 +290,7 @@ abd_free_struct(abd_t *abd)
>  abd_t *
>  abd_alloc(size_t size, boolean_t is_metadata)
>  {
> - if (!zfs_abd_scatter_enabled)
> + if (!zfs_abd_scatter_enabled || size <= zfs_abd_chunk_size)
>   return (abd_alloc_linear(size, is_metadata));

may be `size < zfs_abd_chunk_size`?

>   VERIFY3U(size, <=, SPA_MAXBLOCKSIZE);
> ___
> svn-src-all@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r347410 - in head: . sys/amd64/conf sys/arm/conf sys/arm64/conf sys/i386/conf sys/powerpc/conf sys/riscv/conf sys/sparc64/conf

[Slawa Olhovchenkov]

On Fri, May 10, 2019 at 11:31:21AM -0400, Andrew Gallatin wrote:

> On 2019-05-10 08:44, Slawa Olhovchenkov wrote:
> 
> > pf have ifdef for IPSEC, but don't have support IPSEC_SUPPORT
> > (netpfil/pf/if_pfsync.c).
> > 
> 
> Thanks for pointing this out.  It seems like IPSEC_SUPPORT would work 
> for this.  I've made a patch, and it compiles and the pf module loads.
> However, I have no knowledge of how to test it.  Is this something
> that you use, and which you can test?

I am don't use pf, I am just explore kernel for ame reasson (IPSEC
performance penalty) and see mostly IPSEC code ifdef to

#if defined(IPSEC) || defined(IPSEC_SUPPORT)

and only netpfil/pf/if_pfsync.c ifdef to

#if defined(IPSEC)


> Thanks,
> 
> Drew
> 

> diff --git a/sys/netpfil/pf/if_pfsync.c b/sys/netpfil/pf/if_pfsync.c
> index 45b1e090f95c..cc06637b862e 100644
> --- a/sys/netpfil/pf/if_pfsync.c
> +++ b/sys/netpfil/pf/if_pfsync.c
> @@ -308,7 +308,7 @@ static void   pfsync_bulk_update(void *);
>  static void  pfsync_bulk_fail(void *);
>  
>  static void  pfsync_detach_ifnet(struct ifnet *);
> -#ifdef IPSEC
> +#ifdef IPSEC_SUPPORT
>  static void  pfsync_update_net_tdb(struct pfsync_tdb *);
>  #endif
>  static struct pfsync_bucket  *pfsync_get_bucket(struct pfsync_softc *,
> @@ -1228,7 +1228,7 @@ pfsync_in_tdb(struct pfsync_pkt *pkt, struct mbuf *m, 
> int offset, int count)
>  {
>   int len = count * sizeof(struct pfsync_tdb);
>  
> -#if defined(IPSEC)
> +#if defined(IPSEC_SUPPORT)
>   struct pfsync_tdb *tp;
>   struct mbuf *mp;
>   int offp;
> @@ -1249,7 +1249,7 @@ pfsync_in_tdb(struct pfsync_pkt *pkt, struct mbuf *m, 
> int offset, int count)
>   return (len);
>  }
>  
> -#if defined(IPSEC)
> +#if defined(IPSEC_SUPPORT)
>  /* Update an in-kernel tdb. Silently fail if no tdb is found. */
>  static void
>  pfsync_update_net_tdb(struct pfsync_tdb *pt)

> ___
> svn-src-all@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r347410 - in head: . sys/amd64/conf sys/arm/conf sys/arm64/conf sys/i386/conf sys/powerpc/conf sys/riscv/conf sys/sparc64/conf

[Slawa Olhovchenkov]

On Thu, May 09, 2019 at 10:38:15PM +, Andrew Gallatin wrote:

> Author: gallatin
> Date: Thu May  9 22:38:15 2019
> New Revision: 347410
> URL: https://svnweb.freebsd.org/changeset/base/347410
> 
> Log:
>   Remove IPSEC from GENERIC due to performance issues
>   
>   Having IPSEC compiled into the kernel imposes a non-trivial
>   performance penalty on multi-threaded workloads due to IPSEC
>   refcounting. In my benchmarks of multi-threaded UDP
>   transmit (connected sockets), I've seen a roughly 20% performance
>   penalty when the IPSEC option is included in the kernel (16.8Mpps
>   vs 13.8Mpps with 32 senders on a 14 core / 28 HTT Xeon
>   2697v3)). This is largely due to key_addref() incrementing and
>   decrementing an atomic reference count on the default
>   policy. This cause all CPUs to stall on the same cacheline, as it
>   bounces between different CPUs.
>   
>   Given that relatively few users use ipsec, and that it can be
>   loaded as a module, it seems reasonable to ask those users to
>   load the ipsec module so as to avoid imposing this penalty on the
>   GENERIC kernel. Its my hope that this will make FreeBSD look
>   better in "out of the box" benchmark comparisons with other
>   operating systems.
>   
>   Many thanks to ae for fixing auto-loading of ipsec.ko when
>   ifconfig tries to configure ipsec, and to cy for volunteering
>   to ensure the the racoon ports will load the ipsec.ko module
>   
>   Reviewed by:cem, cy, delphij, gnn, jhb, jpaetzel
>   Differential Revision:  https://reviews.freebsd.org/D20163

pf have ifdef for IPSEC, but don't have support IPSEC_SUPPORT
(netpfil/pf/if_pfsync.c).
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r345040 - in stable/11: share/man/man4 sys/conf sys/dev/cxgbe sys/dev/cxgbe/crypto sys/dev/cxgbe/firmware sys/modules/cxgbe sys/modules/cxgbe/ccr sys/powerpc/conf

[Slawa Olhovchenkov]

On Mon, Mar 11, 2019 at 11:16:10PM +, John Baldwin wrote:

> Author: jhb
> Date: Mon Mar 11 23:16:10 2019
> New Revision: 345040
> URL: https://svnweb.freebsd.org/changeset/base/345040
> 
> Log:
>   MFC 318429,318967,319721,319723,323600,323724,328353-328361,330042,343056:
>   Add a driver for the Chelsio T6 crypto accelerator engine.

Where I can find example/manual of use this engine from userspace?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r335579 - head/sys/vm

[Slawa Olhovchenkov]

On Sat, Jun 23, 2018 at 08:10:10AM +, Jeff Roberson wrote:

> Author: jeff
> Date: Sat Jun 23 08:10:09 2018
> New Revision: 335579
> URL: https://svnweb.freebsd.org/changeset/base/335579
> 
> Log:
>   Sort uma_zone fields according to 64 byte cache line with adjacent line
>   prefetch on 64bit architectures.  Prior to this, two lines were needed
>   for the fast path and each line may fetch an unused adjacent neighbor.
>- Move fields used by the fast path into a single line.
>- Move constants into the adjacent line which is mostly used for
>  the spare bucket alloc 'medium path'.
>- Unpad the mtx which is only used by the fast path and place it in
>  a line with rarely used data.  This aligns the cachelines better and
>  eliminates 128 bytes of wasted space.
>   
>   This gives a 45% improvement on a will-it-scale test on a 24 core machine.

Can this commint mergered to stable/11? Or this commit depends on other commits?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r333133 - head/usr.sbin/pwd_mkdb

[Slawa Olhovchenkov]

On Tue, May 01, 2018 at 02:18:52PM -0400, Ed Maste wrote:

> On 1 May 2018 at 09:01, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> > On Tue, May 01, 2018 at 12:53:46AM +, Ed Maste wrote:
> >
> >> Author: emaste
> >> Date: Tue May  1 00:53:46 2018
> >> New Revision: 333133
> >> URL: https://svnweb.freebsd.org/changeset/base/333133
> >>
> >> Log:
> >>   pwd_mkdb: retire legacy v3 db support (-l option)
> >>
> > May be good idea to check db version before install new binary?
> 
> Perhaps "v3 db" is too brief shorthand: it's not that the database as
> a whole is v3/v4, but that it contains records of one or both types.
> For 15 years we've been emitting v4 and consuming v4 records.

15 years is not aged, I am not sure about some of my databases.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r333133 - head/usr.sbin/pwd_mkdb

[Slawa Olhovchenkov]

On Tue, May 01, 2018 at 12:53:46AM +, Ed Maste wrote:

> Author: emaste
> Date: Tue May  1 00:53:46 2018
> New Revision: 333133
> URL: https://svnweb.freebsd.org/changeset/base/333133
> 
> Log:
>   pwd_mkdb: retire legacy v3 db support (-l option)
>   
>   pwd_mkdb has emitted v4 password database records since 2003 (r113596)
>   in addition to v3, and as of r283981 by default it emitted only v4.
>   As described in r283981, retire the -l legacy option.
>   
>   The -B and -L options were originally added to set the endianness of v3
>   records emitted by pwd_mkdb, but they also set the db hash endiannes and
>   so have been retained temporarily.
>   
>   Announced on the FreeBSD-Current and FreeBSD-Stable lists.  In stable/11
>   the man page contains a deprecation notice, and pwd_mkdb will emit a
>   deprecation notice if the -l option is specified.
>   
>   Reviewed by:delphij, lidl, rgrimes
>   Relnotes:   Yes
>   Sponsored by:   The FreeBSD Foundation
>   Differential Revision:  https://reviews.freebsd.org/D15144

May be good idea to check db version before install new binary?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r332091 - stable/11/sys/vm

[Slawa Olhovchenkov]

On Wed, Apr 11, 2018 at 02:27:48PM -0700, John Baldwin wrote:

> On Wednesday, April 11, 2018 10:49:20 PM Konstantin Belousov wrote:
> > On Wed, Apr 11, 2018 at 08:52:08AM -0700, John Baldwin wrote:
> > > On Monday, April 09, 2018 07:29:09 PM Slawa Olhovchenkov wrote:
> > > > On Fri, Apr 06, 2018 at 09:25:08AM +, Konstantin Belousov wrote:
> > > > 
> > > > > Author: kib
> > > > > Date: Fri Apr  6 09:25:08 2018
> > > > > New Revision: 332091
> > > > > URL: https://svnweb.freebsd.org/changeset/base/332091
> > > > > 
> > > > > Log:
> > > > >   MFC r331760:
> > > > >   Make vm_map_max/min/pmap KBI stable.
> > > > > 
> > > > > Modified:
> > > > >   stable/11/sys/vm/vm_map.c
> > > > >   stable/11/sys/vm/vm_map.h
> > > > > Directory Properties:
> > > > >   stable/11/   (props changed)
> > > > 
> > > > -STABLE still crashed after load vboxnet build on 11.1-RELEASE
> > > > nvidia (build on 11.1-RELEASE) also don't work
> > > 
> > > Yes, this only helps with the future KBI, it doesn't restore the
> > > existing one.  However, r320889 which was committed earlier should
> > > have restored the KBI?
> > 
> > I am not sure.  It might have, but there might be more breakage
> > accumulated.  My current opinion is that both vbox and nvidia (as well as
> > in-tree and out of tree drm modules) must be marked as tied.  The modules
> > definitely depends on much more kernel interfaces than a typical HBA or
> > network controller driver, for which the stability claim is actually
> > intended to apply.
> 
> I do think virtualbox is probably too hard to make work, but I didn't think
> the nvidia driver was that bad.
> 
> I think that for kmods in ports we should consider moving to a different model
> than we currently do where the port installs the source for the kernel
> module to a standard location and we could have a way to rebuild all of the
> modules as needed.  This would permit us to provide PORTS_MODULES-type
> functionality via either ports or packages (and it is a bit more flexible as
> you wouldn't to deinstall/reinstall the package each time you just wanted to
> rebuild the kernel module).
> 
> I would suggest something like /usr/local/src/modules/ and a
> 'LOCAL_MODULES' kernel option that is a list of ' ' to replace
> PORTS_MODULES.  A package could still ship an initial module by default, but
> recompiling the module would either overwrite it, or if the module is built as
> part of the kernel (via LOCAL_MODULES) the new one would be installed with the
> kernel itself into /boot/kernel leaving the one from the package in
> /boot/modules.  For tied modules we could simply build it with a strict
> MODULE_DEPEND line on the kernel so that the pre-built module won't load on
> newer kernels and then encourage the user to use LOCAL_MODULES in pkg-message.
> Using LOCAL_MODULES would be better than PORTS_MODULES as it would DTRT if you
> move kernel to kernel.old during an upgrade, etc.

Hmm, what about packages? I am use nvidia driver as package.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r332091 - stable/11/sys/vm

[Slawa Olhovchenkov]

On Wed, Apr 11, 2018 at 08:52:08AM -0700, John Baldwin wrote:

> On Monday, April 09, 2018 07:29:09 PM Slawa Olhovchenkov wrote:
> > On Fri, Apr 06, 2018 at 09:25:08AM +, Konstantin Belousov wrote:
> > 
> > > Author: kib
> > > Date: Fri Apr  6 09:25:08 2018
> > > New Revision: 332091
> > > URL: https://svnweb.freebsd.org/changeset/base/332091
> > > 
> > > Log:
> > >   MFC r331760:
> > >   Make vm_map_max/min/pmap KBI stable.
> > > 
> > > Modified:
> > >   stable/11/sys/vm/vm_map.c
> > >   stable/11/sys/vm/vm_map.h
> > > Directory Properties:
> > >   stable/11/   (props changed)
> > 
> > -STABLE still crashed after load vboxnet build on 11.1-RELEASE
> > nvidia (build on 11.1-RELEASE) also don't work
> 
> Yes, this only helps with the future KBI, it doesn't restore the
> existing one.  However, r320889 which was committed earlier should
> have restored the KBI?

Sorry, miss you point.
I am update to last stable/11, build and install kernel and check old
modules.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r332365 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Slawa Olhovchenkov]

On Tue, Apr 10, 2018 at 11:17:33AM -0400, Mark Johnston wrote:

> On Tue, Apr 10, 2018 at 05:09:57PM +0300, Slawa Olhovchenkov wrote:
> > On Tue, Apr 10, 2018 at 01:56:06PM +, Mark Johnston wrote:
> > 
> > > Author: markj
> > > Date: Tue Apr 10 13:56:06 2018
> > > New Revision: 332365
> > > URL: https://svnweb.freebsd.org/changeset/base/332365
> > > 
> > > Log:
> > >   Set zfs_arc_free_target to v_free_target.
> > >   
> > >   Page daemon output is now regulated by a PID controller with a setpoint
> > >   of v_free_target. Moreover, the page daemon now wakes up regularly
> > >   rather than waiting for a wakeup from another thread. This means that
> > >   the free page count is unlikely to drop below the old
> > >   zfs_arc_free_target value, and as a result the ARC was not readily
> > >   freeing pages under memory pressure. Address the immediate problem by
> > >   updating zfs_arc_free_target to match the page daemon's new behaviour.
> > 
> > Can you explain some more about new page daemon algo (and reclaim zone
> > free memory)?
> 
> The old algorithm was pretty simple: there was a free page target and
> below that, a wakeup threshold. Any time a thread allocated a page and
> in so doing caused the free page count to drop below the wakeup
> threshold, that thread would wake up the page daemon, which would scan
> the inactive queue and free pages until the free target is reached, or
> the end of the inactive queue was reached.
> 
> This is simple and easy to reason about, but has some drawbacks. When
> memory pressure is constant, it leads to bursts of CPU usage and lock
> contention. The static watermarks may also be insufficient for some
> demanding workloads. In particular, the wakeup threshold might be too
> low, thus allowing the free page count to drop to dangerous levels and
> triggering expensive memory shortage handling (i.e., VM_WAIT).
> 
> The new algorithm uses a control loop to dynamically compute a target
> for each scan of the inactive queue. The loop takes as input the
> magnitude of the page shortage (v_free_target - v_free_count) and keeps
> track of the rate of change of this difference (i.e., the rate at which
> free pages are being consumed) and the sum of this difference over time
> (i.e., a cumulative value for the magnitude of recent page shortages).
> These factors are used to compute "shortage", the number of pages to
> reclaim with the goal of maintaining a free page count of v_free_target.
> 
> The effect of the new algorithm is that the page daemon runs more
> frequently but for shorter durations, so its CPU usage is more even. It
> responds dynamically to the demands of the workload, so the shortcomings
> of a pair of static watermarks are gone.
> 
> r329882 doesn't really change anything with respect to reclamation of
> pages from UMA zones. There are some plans to address shortcomings there
> in the near future though.

Thank, very nice explain.
IMHO, in this case for ZFS best is old zfs_arc_free_target: too close
zfs_arc_free_target to vm_cnt.v_free_min can cause too often run
arc_target correction and cause CPU consumption and memory subsystem
overuse.
ZFS need more correct pressure, ZFS-specific, and I am try it in D7538.

> > PS: zfs need some more time for free pages from ARC. Also, vanila zfs
> > have broken logic for count used and free ARC's memory. For most
> > correctly count system-wide used and free memory need accounting
> > in-zone free memory.
> 
> Yes, there is a number of problems in this area predating r329882. This
> commit is really just a bandaid.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r332365 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Slawa Olhovchenkov]

On Tue, Apr 10, 2018 at 01:56:06PM +, Mark Johnston wrote:

> Author: markj
> Date: Tue Apr 10 13:56:06 2018
> New Revision: 332365
> URL: https://svnweb.freebsd.org/changeset/base/332365
> 
> Log:
>   Set zfs_arc_free_target to v_free_target.
>   
>   Page daemon output is now regulated by a PID controller with a setpoint
>   of v_free_target. Moreover, the page daemon now wakes up regularly
>   rather than waiting for a wakeup from another thread. This means that
>   the free page count is unlikely to drop below the old
>   zfs_arc_free_target value, and as a result the ARC was not readily
>   freeing pages under memory pressure. Address the immediate problem by
>   updating zfs_arc_free_target to match the page daemon's new behaviour.

Can you explain some more about new page daemon algo (and reclaim zone
free memory)?

PS: zfs need some more time for free pages from ARC. Also, vanila zfs
have broken logic for count used and free ARC's memory. For most
correctly count system-wide used and free memory need accounting
in-zone free memory.

>  arc_free_target_init(void *unused __unused)
>  {
>  
> - zfs_arc_free_target = (vm_cnt.v_free_min / 10) * 11;
> + zfs_arc_free_target = vm_cnt.v_free_target;
>  }
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r332091 - stable/11/sys/vm

[Slawa Olhovchenkov]

On Fri, Apr 06, 2018 at 09:25:08AM +, Konstantin Belousov wrote:

> Author: kib
> Date: Fri Apr  6 09:25:08 2018
> New Revision: 332091
> URL: https://svnweb.freebsd.org/changeset/base/332091
> 
> Log:
>   MFC r331760:
>   Make vm_map_max/min/pmap KBI stable.
> 
> Modified:
>   stable/11/sys/vm/vm_map.c
>   stable/11/sys/vm/vm_map.h
> Directory Properties:
>   stable/11/   (props changed)

-STABLE still crashed after load vboxnet build on 11.1-RELEASE
nvidia (build on 11.1-RELEASE) also don't work
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r327559 - in head: . sys/net

[Slawa Olhovchenkov]

On Fri, Jan 05, 2018 at 11:59:30PM +0700, Eugene Grosbein wrote:

> 05.01.2018 21:38, Slawa Olhovchenkov wrote:
> 
> >>> Irrelevant to RSS and etc. flowid distribution in lacp case work very
> >>> bad. This is good and must be MFC (IMHO).
> >>
> >> It may work bad depending on NIC and/or traffic type.
> >> It works just fine in common case of IP forwarding for packets with 
> >> TCP/UDP inside.
> >>
> >> It can be easily disabled locally for specific cases when it does not work.
> > 
> > Packet distrubuting on network equipment (lacp case) w/ enabled flowid cause
> > uneven queue distributing.
> 
> Once again: this heavily depends on local environment and this is not true 
> for many cases.

For any case resolving cavears need uncommon skills. It's true.
Don't using flowid from hardware need negligible CPU power.
Safe is disable flowid bDefault disable flowid is safe way w/o
performace penalty.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r327559 - in head: . sys/net

[Slawa Olhovchenkov]

On Fri, Jan 05, 2018 at 08:36:48PM +0700, Eugene Grosbein wrote:

> 05.01.2018 20:11, Slawa Olhovchenkov wrote:
> 
> > Irrelevant to RSS and etc. flowid distribution in lacp case work very
> > bad. This is good and must be MFC (IMHO).
> 
> It may work bad depending on NIC and/or traffic type.
> It works just fine in common case of IP forwarding for packets with TCP/UDP 
> inside.
> 
> It can be easily disabled locally for specific cases when it does not work.
> 

Packet distrubuting on network equipment (lacp case) w/ enabled flowid cause
uneven queue distributing. Yes, this is may be disabled locally, but
diagnostic this root cause need uncommon skills.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r327559 - in head: . sys/net

[Slawa Olhovchenkov]

On Fri, Jan 05, 2018 at 03:50:31AM +0700, Eugene Grosbein wrote:

> 05.01.2018 3:05, Steven Hartland wrote:
> 
> > Author: smh
> > Date: Thu Jan  4 20:05:47 2018
> > New Revision: 327559
> > URL: https://svnweb.freebsd.org/changeset/base/327559
> > 
> > Log:
> >   Disabled the use of flowid for lagg by default
> >   
> >   Disabled the use of RSS hash from the network card aka flowid for
> >   lagg(4) interfaces by default as it's currently incompatible with
> >   the lacp and loadbalance protocols.
> >   
> >   The incompatibility is due to the fact that the flowid isn't know
> >   for the first packet of a new outbound stream which can result in
> >   the hash calculation method changing and hence a stream being
> >   incorrectly split across multiple interfaces during normal
> >   operation.
> >   
> >   This can be re-enabled by setting the following in loader.conf:
> >   net.link.lagg.default_use_flowid="1"
> >   
> >   Discussed with: kmacy
> >   Sponsored by: Multiplay
> 
> RSS by definition has meaning to received stream. What is "outbound" stream
> in this context, why can the hash calculatiom method change and what exactly
> does it mean "a stream being incorrectly split"?
> 
> Defaults should not be changed so easily just because they are not optimal
> for some specific case. Each lagg has its own setting for flowid usage
> and why one cannot just use "ifconfig lagg0 -use_flowid" for such cases?

Irrelevant to RSS and etc. flowid distribution in lacp case work very
bad. This is good and must be MFC (IMHO).
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r323081 - stable/10/sys/conf

[Slawa Olhovchenkov]

On Fri, Sep 01, 2017 at 12:16:03AM +, Marius Strobl wrote:

> Author: marius
> Date: Fri Sep  1 00:16:03 2017
> New Revision: 323081
> URL: https://svnweb.freebsd.org/changeset/base/323081
> 
> Log:
>   Update stable/10 to BETA3 in preparation for 10.4-BETA3 builds.
>   
>   Approved by:re (implicit)
> 
> Modified:
>   stable/10/sys/conf/newvers.sh

NETAMP still not working on ix card.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r322863 - head/sys/cam

[Slawa Olhovchenkov]

On Fri, Aug 25, 2017 at 09:33:35AM -0600, Warner Losh wrote:

> On Fri, Aug 25, 2017 at 7:35 AM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> 
> > On Thu, Aug 24, 2017 at 10:11:10PM +, Warner Losh wrote:
> >
> > > Author: imp
> > > Date: Thu Aug 24 22:11:10 2017
> > > New Revision: 322863
> > > URL: https://svnweb.freebsd.org/changeset/base/322863
> > >
> > > Log:
> > >   Expand the latency tracking array from 1.024s to 8.192s to help track
> > >   extreme outliers from dodgy drives. Adjust comments to reflect this,
> > >   and make sure that the number of latency buckets match in the two
> > >   places where it matters.
> >
> > May be up to 1min?
> >
> 
> I'm not sure what additional data you'll get between "totally sucks, at
> least 8s latency" and "totally sucks, at least 32s." or "totally sucks, at
> least 64s" though the latter isn't possible with the default timeouts...
> 
> I'm planning on adding a 'max' latency that's self-resetting instead of
> expanding the bucket upwards. I'm also contemplating expanding it down to
> 100us or even 10us since nda serves nvme drives which easily can be sub
> 100us.

This is just stat data?
Don't produce error messages about timeout commands and etc?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r322863 - head/sys/cam

[Slawa Olhovchenkov]

On Thu, Aug 24, 2017 at 10:11:10PM +, Warner Losh wrote:

> Author: imp
> Date: Thu Aug 24 22:11:10 2017
> New Revision: 322863
> URL: https://svnweb.freebsd.org/changeset/base/322863
> 
> Log:
>   Expand the latency tracking array from 1.024s to 8.192s to help track
>   extreme outliers from dodgy drives. Adjust comments to reflect this,
>   and make sure that the number of latency buckets match in the two
>   places where it matters.

May be up to 1min?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r321825 - in stable/10: . gnu/usr.bin/groff/tmac lib/clang sys/conf

[Slawa Olhovchenkov]

On Mon, Jul 31, 2017 at 10:19:39PM +, Marius Strobl wrote:

> Author: marius
> Date: Mon Jul 31 22:19:39 2017
> New Revision: 321825
> URL: https://svnweb.freebsd.org/changeset/base/321825
> 
> Log:
>   Update stable/10 from 10.3-STABLE to 10.4-PRERELEASE as part of
>   the 10.4 release cycle, also belatedly marking the official start
>   of the code slush.
>   
>   Set the default mdoc(7) version to 10.4, and update the clang(1)
>   TARGET_TRIPLE to reflect 10.4. While at it, add missing FreeBSD
>   major versions to mdoc(7).
>   
>   Approved by:re (implicit)

ix netmap code is broken for me in 10-STABLE.
Could ypou please test and/or confirm and ask responsible ones to fix this 
problem
before release?

https://lists.freebsd.org/pipermail/svn-src-all/2017-June/147797.html

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r317711 - stable/10/sys/dev/ixgbe

[Slawa Olhovchenkov]

On Tue, May 02, 2017 at 10:57:27PM +, Eric Joyner wrote:

> Author: erj
> Date: Tue May  2 22:57:27 2017
> New Revision: 317711
> URL: https://svnweb.freebsd.org/changeset/base/317711
> 
> Log:
>   ixgbe(4): Fix build issue when compiling with netmap enabled
>   
>   Sponsored by:   Intel Corporation

After this (and r315333) netmap like broken: packets don't received
anymore.

ix0:  port 
0xd020-0xd03f mem 0xfb28-0xfb2f,0xfb704000-0xfb707fff irq 34 at device 
0.0 on pci5
work at r313387
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r317529 - in stable: 10/sys/sys 11/sys/sys

[Slawa Olhovchenkov]

On Tue, May 23, 2017 at 07:43:43AM -0500, Eric Badger wrote:

> On 05/10/2017 07:57 AM, Slawa Olhovchenkov wrote:
> > On Tue, May 09, 2017 at 09:14:20PM -0500, Eric Badger wrote:
> >
> >> On 05/09/2017 03:32 PM, Slawa Olhovchenkov wrote:
> >>> On Thu, Apr 27, 2017 at 10:28:50PM +, Eric Badger wrote:
> >>>
> >>>> Author: badger
> >>>> Date: Thu Apr 27 22:28:49 2017
> >>>> New Revision: 317529
> >>>> URL: https://svnweb.freebsd.org/changeset/base/317529
> >>>>
> >>>> Log:
> >>>>   Move td_sigqueue to the end of struct thread
> >>>>
> >>>>   In order to preserve KBI in stable branches, replace the existing
> >>>>   td_sigqueue slot with padding and move the expanded (as of r315949)
> >>>>   td_sigqueue to the end of the struct.
> >>>>
> >>>>   Reported by:   jhb
> >>>>   Suggested by:  kib
> >>>>   Reviewed by:   jhb, kib, vangyzen
> >>>>   Sponsored by:  Dell EMC
> >>>>   Differential Revision: https://reviews.freebsd.org/D10515
> >>>>
> >>>> Modified:
> >>>>   stable/10/sys/sys/proc.h
> >>>
> >>> Is this resolve only crash related to nvidia-driver?
> >>> Like virtualbox related crash still occur.
> >>>
> >>
> >> Yes, this was intended to address nvidia driver crashes. Is the virtual
> >> box problem the same as the one described here?
> >>
> >> https://lists.freebsd.org/pipermail/freebsd-stable/2017-March/087028.html
> >
> > I am use GENERIC and GENERIC kernel just reboot, w/o create crush
> > dump.
> > I mean need to add DDB and KDB to kernel config?
> >
> 
> This should be fixed as of r318743.

Work for me, 10x!
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r317529 - in stable: 10/sys/sys 11/sys/sys

[Slawa Olhovchenkov]

On Tue, May 09, 2017 at 09:14:20PM -0500, Eric Badger wrote:

> On 05/09/2017 03:32 PM, Slawa Olhovchenkov wrote:
> > On Thu, Apr 27, 2017 at 10:28:50PM +, Eric Badger wrote:
> >
> >> Author: badger
> >> Date: Thu Apr 27 22:28:49 2017
> >> New Revision: 317529
> >> URL: https://svnweb.freebsd.org/changeset/base/317529
> >>
> >> Log:
> >>   Move td_sigqueue to the end of struct thread
> >>
> >>   In order to preserve KBI in stable branches, replace the existing
> >>   td_sigqueue slot with padding and move the expanded (as of r315949)
> >>   td_sigqueue to the end of the struct.
> >>
> >>   Reported by: jhb
> >>   Suggested by:kib
> >>   Reviewed by: jhb, kib, vangyzen
> >>   Sponsored by:Dell EMC
> >>   Differential Revision:   https://reviews.freebsd.org/D10515
> >>
> >> Modified:
> >>   stable/10/sys/sys/proc.h
> >
> > Is this resolve only crash related to nvidia-driver?
> > Like virtualbox related crash still occur.
> >
> 
> Yes, this was intended to address nvidia driver crashes. Is the virtual 
> box problem the same as the one described here?
> 
> https://lists.freebsd.org/pipermail/freebsd-stable/2017-March/087028.html

I am use GENERIC and GENERIC kernel just reboot, w/o create crush
dump.
I mean need to add DDB and KDB to kernel config?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r317529 - in stable: 10/sys/sys 11/sys/sys

[Slawa Olhovchenkov]

On Thu, Apr 27, 2017 at 10:28:50PM +, Eric Badger wrote:

> Author: badger
> Date: Thu Apr 27 22:28:49 2017
> New Revision: 317529
> URL: https://svnweb.freebsd.org/changeset/base/317529
> 
> Log:
>   Move td_sigqueue to the end of struct thread
>   
>   In order to preserve KBI in stable branches, replace the existing
>   td_sigqueue slot with padding and move the expanded (as of r315949)
>   td_sigqueue to the end of the struct.
>   
>   Reported by:jhb
>   Suggested by:   kib
>   Reviewed by:jhb, kib, vangyzen
>   Sponsored by:   Dell EMC
>   Differential Revision:  https://reviews.freebsd.org/D10515
> 
> Modified:
>   stable/10/sys/sys/proc.h

Is this resolve only crash related to nvidia-driver?
Like virtualbox related crash still occur.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r317269 - in head/sys: fs/nfs sys

[Slawa Olhovchenkov]

On Fri, Apr 21, 2017 at 08:08:10PM +, Rick Macklem wrote:

> Author: rmacklem
> Date: Fri Apr 21 20:08:10 2017
> New Revision: 317269
> URL: https://svnweb.freebsd.org/changeset/base/317269
> 
> Log:
>   Set default uid/gid to nobody/nogroup for NFSv4 mapping.
>   
>   The default uid/gid for NFSv4 are set by the nfsuserd(8) daemon.
>   However, they were 0 until the nfsuserd(8) was run. Since it is
>   possible to use NFSv4 without running the nfsuserd(8) daemon, set them
>   to nobody/nogroup initially.
>   Without this patch, the values would be set by the nfsuserd(8) daemon
>   and left changed even if the nfsuserd(8) daemon was killed. The default
>   values of 0 meant that setting a group to "wheel" would fail even when
>   done by root.
>   It also adds a definition of GID_NOGROUP to sys/conf.h.
>   
>   Discussed on:   freebsd-current@
>   MFC after:  2 weeks

Can you also look to this problem
https://lists.freebsd.org/pipermail/freebsd-stable/2012-March/066868.html
?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r317094 - head/share/mk

[Slawa Olhovchenkov]

On Thu, Apr 20, 2017 at 09:58:10AM -0700, John Baldwin wrote:

> > Well it seems it can do some rather important trivial things, like post
> > mortem process kernel dumps during savecore processing helping users
> > submit a kernel panic bugzilla with more than just traceback info.
> 
> Only somewhat.  You should actually try to use kgdb and compare it to the
> kgdb in ports.

I am don't see many difference: both do strange results, both crashed.
For kernel and userland too.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r317143 - in head/sys/cam: . ata scsi

[Slawa Olhovchenkov]

On Wed, Apr 19, 2017 at 03:04:53PM +, Scott Long wrote:

> Author: scottl
> Date: Wed Apr 19 15:04:52 2017
> New Revision: 317143
> URL: https://svnweb.freebsd.org/changeset/base/317143
> 
> Log:
>   Add infrastructure to the ATA and SCSI transports that supports
>   using a driver-supplied sbuf for printing device discovery
>   announcements. This helps ensure that messages to the console
>   will be properly serialized (through sbuf_putbuf) and not be
>   truncated and interleaved with other messages. The
>   infrastructure mirrors the existing xpt_announce_periph()
>   entry point and is opt-in for now. No content or formatting
>   changes are visible to the operator other than the new coherency.
>   
>   While here, eliminate the stack usage of the temporary
>   announcement buffer in some of the drivers. It's moved to the
>   softc for now, but future work will eliminate it entirely by
>   making the code flow more linear. Future work will also address
>   locking so that the sbufs can be dynamically sized.
>   
>   The scsi_da, scs_cd, scsi_ses, and ata_da drivers are converted
>   at this point, other drivers can be converted at a later date.
>   A tunable+sysctl, kern.cam.announce_nosbuf, exists for testing
>   purposes but will be removed later.
>   
>   TODO:
>   Eliminate all of the code duplication and temporary buffers.  The
>   old printf-based methods will be retired, and xpt_announce_periph()
>   will just be a wrapper that uses a dynamically sized sbuf.  This
>   requires that the register and deregister paths be made malloc-safe,
>   which they aren't currently.

Thanks!
MFC planed?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r317094 - head/share/mk

[Slawa Olhovchenkov]

On Tue, Apr 18, 2017 at 12:45:25PM -0700, John Baldwin wrote:

> On Tuesday, April 18, 2017 07:30:13 PM Slawa Olhovchenkov wrote:
> > On Tue, Apr 18, 2017 at 04:27:48PM +, John Baldwin wrote:
> > 
> > > Author: jhb
> > > Date: Tue Apr 18 16:27:48 2017
> > > New Revision: 317094
> > > URL: https://svnweb.freebsd.org/changeset/base/317094
> > > 
> > > Log:
> > >   Disable in-tree GDB by default on x86, mips, and powerpc.
> > >   
> > >   GDB in ports contains all of the functionality as GDB in base
> > >   (including kgdb) for these platforms along with additional
> > >   functionality.  In-tree GDB remains enabled on ARM and sparc64.
> > >   GDB in ports does not currently support kernel debugging on arm,
> > >   and ports GDB for sparc64 has not been tested (though it does
> > >   include sparc64 support).
> > >   
> > >   Reviewed by:bdrewery, emaste, imp
> > >   Relnotes:   yes
> > >   Sponsored by:   DARPA / AFRL
> > >   Differential Revision:  https://reviews.freebsd.org/D10399
> > 
> > Generating core.txt now complety broken?
> 
> No.  crashinfo has supported gdb from ports for quite a while now.
> If you 'pkg install gdb' crashinfo defaults to using the ports gdb over
> the base one already.

I am about clean install, w/o ports.
Also, how to generate core.txt after crash, reboot and install gdb
from ports? (port instaled after crash)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r317094 - head/share/mk

[Slawa Olhovchenkov]

On Tue, Apr 18, 2017 at 04:27:48PM +, John Baldwin wrote:

> Author: jhb
> Date: Tue Apr 18 16:27:48 2017
> New Revision: 317094
> URL: https://svnweb.freebsd.org/changeset/base/317094
> 
> Log:
>   Disable in-tree GDB by default on x86, mips, and powerpc.
>   
>   GDB in ports contains all of the functionality as GDB in base
>   (including kgdb) for these platforms along with additional
>   functionality.  In-tree GDB remains enabled on ARM and sparc64.
>   GDB in ports does not currently support kernel debugging on arm,
>   and ports GDB for sparc64 has not been tested (though it does
>   include sparc64 support).
>   
>   Reviewed by:bdrewery, emaste, imp
>   Relnotes:   yes
>   Sponsored by:   DARPA / AFRL
>   Differential Revision:  https://reviews.freebsd.org/D10399

Generating core.txt now complety broken?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r316938 - head/sbin/savecore

[Slawa Olhovchenkov]

On Sat, Apr 15, 2017 at 07:00:57AM -0700, Rodney W. Grimes wrote:

> > On Fri, Apr 14, 2017 at 03:05:25PM -0700, Mark Johnston wrote:
> > 
> > > > And with textdumps available, the benefit
> > > > of having compression is limited because we can request for minidump
> > > > or full dumps only when the textdumps are not good enough for
> > > > diagnosing the kernel bug.
> > > 
> > > Sure, but in this case the compression may be vital.
> > > 
> > > > 
> > > > I don't think security (e.g. leaking information because of the use of
> > > > compression) is a very big concern in this context because in order
> > > > for the potential attacker to read the raw material needs a
> > > > compromised system (unlike an attack from the network, where someone
> > > > who controls the network would have access to the raw material); the
> > > > dump is usually quite large, and measuring downtime would be hard at
> > > > that scale.
> > > 
> > > Ok.
> > > 
> > > > 
> > > > By the way (not meant to bikeshed) if I was to do this I'd prefer
> > > > using lz4 or something that compresses faster than zlib.
> > > 
> > > I agree, but I think the existing lz4 implementation in the kernel is
> > > not so well suited to running after a panic. It seems fixable, but
> > > compression speed also isn't hugely important here IMO.
> > 
> > On production system this is downtime.
> > For may case, dumped about 32GB (from 256GB RAM). This is take several
> > minutes. Can compression increase this to hour?
> 
> On productions systems the compression layer of dump may very well
> be a win situation depending on choosen algorith (you want something
> fairly fast, but still effective).  If your rate to compress bytes
> is close to the disk write bandwith you have an over all win caused
> by writting less to disk.
> 
> Someone who enjoys math should write an equation for given
> compression bandwidth cb and given disk bandwidth db and
> compression ratio cr what do the curves look like? 
> 
> IIRC we measure cpu/memory bandwidth in the 10'sG bytes/sec

wrong. single thread cpu/memory bandwidth very different on i7 and e5
cpu (e5 less, about 6 GB/s).

> range, compression should be some place under that, and
> our disk bandwidth even on SSD is in the 500MB range,
> even the fastest 15k rpm spinning rust is in the <200MB
> range, we should be able to compress at a higher rate than
> this.

yes.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r316938 - head/sbin/savecore

[Slawa Olhovchenkov]

On Fri, Apr 14, 2017 at 03:05:25PM -0700, Mark Johnston wrote:

> > And with textdumps available, the benefit
> > of having compression is limited because we can request for minidump
> > or full dumps only when the textdumps are not good enough for
> > diagnosing the kernel bug.
> 
> Sure, but in this case the compression may be vital.
> 
> > 
> > I don't think security (e.g. leaking information because of the use of
> > compression) is a very big concern in this context because in order
> > for the potential attacker to read the raw material needs a
> > compromised system (unlike an attack from the network, where someone
> > who controls the network would have access to the raw material); the
> > dump is usually quite large, and measuring downtime would be hard at
> > that scale.
> 
> Ok.
> 
> > 
> > By the way (not meant to bikeshed) if I was to do this I'd prefer
> > using lz4 or something that compresses faster than zlib.
> 
> I agree, but I think the existing lz4 implementation in the kernel is
> not so well suited to running after a panic. It seems fixable, but
> compression speed also isn't hugely important here IMO.

On production system this is downtime.
For may case, dumped about 32GB (from 256GB RAM). This is take several
minutes. Can compression increase this to hour?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r316938 - head/sbin/savecore

[Slawa Olhovchenkov]

On Fri, Apr 14, 2017 at 01:45:22PM -0700, Ngie Cooper (yaneurabeya) wrote:

> 
> > On Apr 14, 2017, at 13:42, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> 
> …
> 
> > No, something like:
> > % swapinfo
> > Device  1K-blocks UsedAvail Capacity
> > /dev/ada0p2  335544320 33554432 0%
> > /dev/ada1p2  335544320 33554432 0%
> > Total671088640 67108864 0%
> 
> Striping dumps across multiple swap devices isn’t supported. Sorry.

What about support in the future?

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r316938 - head/sbin/savecore

[Slawa Olhovchenkov]

On Fri, Apr 14, 2017 at 01:33:36PM -0700, Ngie Cooper (yaneurabeya) wrote:

> 
> > On Apr 14, 2017, at 13:26, Larry Rosenman <l...@lerctr.org> wrote:
> > 
> > On 4/14/17, 3:19 PM, "Ngie Cooper (yaneurabeya)" 
> > <owner-svn-src-...@freebsd.org on behalf of yaneurab...@gmail.com> wrote:
> > 
> >> On Apr 14, 2017, at 13:14, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> >> 
> >> On Fri, Apr 14, 2017 at 01:49:51PM -0600, Alan Somers wrote:
> >> 
> >>> On Fri, Apr 14, 2017 at 1:41 PM, Ngie Cooper <n...@freebsd.org> wrote:
> >>>> Author: ngie
> >>>> Date: Fri Apr 14 19:41:48 2017
> >>>> New Revision: 316938
> >>>> URL: https://svnweb.freebsd.org/changeset/base/316938
> >>>> 
> >>>> Log:
> >>>> savecore: fix space calculation with respect to `minfree` in 
> >>>> check_space(..)
> >>>> 
> >>>> - Use strtoll(3) instead of atoi(3), because atoi(3) limits the
> >>>>   representable data to INT_MAX. Check the values received from
> >>>>   strtoll(3), trimming trailing whitespace off the end to maintain
> >>>>   POLA.
> >>>> - Use `KiB` instead of `kB` when describing free space, total space,
> >>>>   etc. I am now fully aware of `KiB` being the IEC standard for 1024
> >>>>   bytes and `kB` being the IEC standard for 1000 bytes.
> >>>> - Store available number of KiB in `available` so it can be more
> >>>>   easily queried and compared to ensure that there are enough KiB to
> >>>>   store the dump image on disk.
> >>>> - Print out the reserved space on disk, per `minfree`, so end-users
> >>>>   can troubleshoot why check_space(..) is reporting that there isn't
> >>>>   enough free space.
> >>>> 
> >>>> MFC after:7 weeks
> >>>> Reviewed by:  Anton Rang <r...@acm.com> (earlier diff), cem (earlier 
> >>>> diff)
> >>>> Tested with:  positive/negative cases (see review); make tinderbox
> >>>> Sponsored by: Dell EMC Isilon
> >>>> Differential Revision:D10379
> >>> 
> >>> The free space calculation is still uselessly conservative, because it
> >>> doesn't account for the fact that core dumps will always be either
> >>> spare or compressed.  The result is that savecore will frequently
> >>> refuse to save corefiles even when there's plenty of space.  I
> >>> proposed removing the space check altogether in
> >>> https://reviews.freebsd.org/D2587.  However, I agreed to wait until
> >>> after the compressed core dump feature was merged, because then mostly
> >>> accurate space checks will be possible.  AFAIK the compressed core
> >>> dump feature still hasn't been finished.
> >> 
> >> Is posible (in the future) to use multiple swaps (on multiple disks)
> >> for save core dumps?
> > 
> >Multiple swap devices is already handled by savecore(8), if one uses 
> > fstab(5) or dumpon(8). Otherwise, you must invoke savecore(8) on individual 
> > devices.
> > 
> >As far as saving to multiple disks is concerned, I would hope that one 
> > is using a redundancy capable filesystem (zfs) or RAID-like technology 
> > (gmirror, graid, LSI Fusion’s RAID product line) to stripe and/or mirror 
> > the data across multiple disks.
> 
> …
> 
> > How do I use multiple devices to have the system dump on all of my swap?  I 
> > got a message about not enough space, but there (I think) was enough 
> > between multiple drives….
> 
> Something like:
> 
> - Create a zpool
> - Mount zpool to /crashdumps
> - Change dumpdir in /etc/rc.conf to be /crashdumps, e.g., echo 
> ‘dumpdir=/crashdumps’
> 
> ?

No, something like:
% swapinfo
Device  1K-blocks UsedAvail Capacity
/dev/ada0p2  335544320 33554432 0%
/dev/ada1p2  335544320 33554432 0%
Total671088640 67108864 0%

> 
> PS The issue with lack of space might be the issue that Alan brought up 
> earlier with compressed dumps and overly conservative free space checks, or 
> it might be the fact that dumpdir (default: /var/crash) is full.


___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r316938 - head/sbin/savecore

[Slawa Olhovchenkov]

On Fri, Apr 14, 2017 at 01:49:51PM -0600, Alan Somers wrote:

> On Fri, Apr 14, 2017 at 1:41 PM, Ngie Cooper  wrote:
> > Author: ngie
> > Date: Fri Apr 14 19:41:48 2017
> > New Revision: 316938
> > URL: https://svnweb.freebsd.org/changeset/base/316938
> >
> > Log:
> >   savecore: fix space calculation with respect to `minfree` in 
> > check_space(..)
> >
> >   - Use strtoll(3) instead of atoi(3), because atoi(3) limits the
> > representable data to INT_MAX. Check the values received from
> > strtoll(3), trimming trailing whitespace off the end to maintain
> > POLA.
> >   - Use `KiB` instead of `kB` when describing free space, total space,
> > etc. I am now fully aware of `KiB` being the IEC standard for 1024
> > bytes and `kB` being the IEC standard for 1000 bytes.
> >   - Store available number of KiB in `available` so it can be more
> > easily queried and compared to ensure that there are enough KiB to
> > store the dump image on disk.
> >   - Print out the reserved space on disk, per `minfree`, so end-users
> > can troubleshoot why check_space(..) is reporting that there isn't
> > enough free space.
> >
> >   MFC after:7 weeks
> >   Reviewed by:  Anton Rang  (earlier diff), cem (earlier diff)
> >   Tested with:  positive/negative cases (see review); make tinderbox
> >   Sponsored by: Dell EMC Isilon
> >   Differential Revision:D10379
> 
> The free space calculation is still uselessly conservative, because it
> doesn't account for the fact that core dumps will always be either
> spare or compressed.  The result is that savecore will frequently
> refuse to save corefiles even when there's plenty of space.  I
> proposed removing the space check altogether in
> https://reviews.freebsd.org/D2587.  However, I agreed to wait until
> after the compressed core dump feature was merged, because then mostly
> accurate space checks will be possible.  AFAIK the compressed core
> dump feature still hasn't been finished.

Is posible (in the future) to use multiple swaps (on multiple disks)
for save core dumps?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r316699 - head/sys/net

[Slawa Olhovchenkov]

On Tue, Apr 11, 2017 at 11:49:56AM -0700, Rodney W. Grimes wrote:

> [ Charset UTF-8 unsupported, converting... ]
> > On 11.04.2017 19:51, Rodney W. Grimes wrote:
> > >> Modified: head/sys/net/if_gre.c
> > >> ==
> > >> --- head/sys/net/if_gre.cTue Apr 11 08:29:12 2017
> > >> (r316698)
> > >> +++ head/sys/net/if_gre.cTue Apr 11 08:56:18 2017
> > >> (r316699)
> > >> @@ -88,7 +88,7 @@ __FBSDID("$FreeBSD$");
> > >>  #include 
> > >>  #include 
> > >>  
> > >> -#define GREMTU  1500
> > >> +#define GREMTU  1476
> > > 
> > > I would of thought that this was
> > > #define   GREMTU  ETHERMTU
> > > and now should probably be:
> > > #define   GREMTU  ETHERMTU - gre_hlen; 
> > > Or what ever the approprite sizeof(foo) is;
> > 
> > I just returned back constants that were here :)
> 
> Can we try to improve on this, or maybe just ignore it?
> 
> > The man page says:
> >  "The MTU of gre interfaces is set to 1476 by default, to match the
> >   value used by Cisco routers."
> 
> That might need some clean up too?
> 
> > > Isn't this arguably wrong in the face of JumboFrames?
> > >
> > 
> > I don't see why it may be wrong for jumbo frames. The default MTU value
> > used by any interfaces is ETHERMTU, if you know that your NIC supports
> > jumbo frames, you will configure specific MTU value.
> > If you want 9k MTU on gre(4), you should configure it.
> 
> I may some day want to #define ETHERMTU 9000 and just have all the right
> magic happen, wouldnt that be nice?

Not before 2038.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r316372 - stable/11/etc

[Slawa Olhovchenkov]

On Sun, Apr 02, 2017 at 09:39:47AM -0600, Alan Somers wrote:

> On Sun, Apr 2, 2017 at 5:15 AM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> > On Sat, Apr 01, 2017 at 08:51:22PM +, Alan Somers wrote:
> >
> >> Author: asomers
> >> Date: Sat Apr  1 20:51:22 2017
> >> New Revision: 316372
> >> URL: https://svnweb.freebsd.org/changeset/base/316372
> >>
> >> Log:
> >>   MFC r314341:
> >>
> >>   Update devd.conf for ports change 421360
> >>
> >>   Ports change 421360 changed the name and UID of the postgres user
> >
> > This is not good solution, IMHO.
> > System w/ PostgreSQL installed before 421360 after update to r314341
> > will be break.
> >
> > IMHO best is to have (some time) both rules: for uid 70 and 770.
> 
> I disagree, Slawa, because this devd.conf rule is moot in the default
> install.  That's becauses there is no matching rctl.conf rule.  It's
> really just an example.  In fact, I don't even know if it refers to
> any actual memory leak in postgresql, or just a hypothetical one.  I'm
> pretty sure that Trasz only added it in r220168 as an example of how
> to write a RCTL rule in devd.conf.

Thanks for clarification.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r316372 - stable/11/etc

[Slawa Olhovchenkov]

On Sat, Apr 01, 2017 at 08:51:22PM +, Alan Somers wrote:

> Author: asomers
> Date: Sat Apr  1 20:51:22 2017
> New Revision: 316372
> URL: https://svnweb.freebsd.org/changeset/base/316372
> 
> Log:
>   MFC r314341:
>   
>   Update devd.conf for ports change 421360
>   
>   Ports change 421360 changed the name and UID of the postgres user

This is not good solution, IMHO.
System w/ PostgreSQL installed before 421360 after update to r314341
will be break.

IMHO best is to have (some time) both rules: for uid 70 and 770.

>   Reviewed by:trasz, imp, girgen
>   MFC after:  3 weeks
>   Sponsored by:   Spectra Logic Corp
>   Differential Revision:  https://reviews.freebsd.org/D9746
> 
> Modified:
>   stable/11/etc/devd.conf
> Directory Properties:
>   stable/11/   (props changed)
> 
> Modified: stable/11/etc/devd.conf
> ==
> --- stable/11/etc/devd.conf   Sat Apr  1 20:38:12 2017(r316371)
> +++ stable/11/etc/devd.conf   Sat Apr  1 20:51:22 2017(r316372)
> @@ -312,10 +312,10 @@ notify 10 {
>  };
>  
>  # This example works around a memory leak in PostgreSQL, restarting
> -# it when the "user:pgsql:swap:devctl=1G" rctl(8) rule gets triggered.
> +# it when the "user:postgres:swap:devctl=1G" rctl(8) rule gets triggered.
>  notify 0 {
>   match "system"  "RCTL";
> - match "rule""user:70:swap:.*";
> + match "rule""user:770:swap:.*";
>   action  "/usr/local/etc/rc.d/postgresql restart";
>  };
>  
> ___
> svn-src-all@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315834 - stable/11/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Slawa Olhovchenkov]

On Thu, Mar 23, 2017 at 08:00:16AM +, Andriy Gapon wrote:

> Author: avg
> Date: Thu Mar 23 08:00:16 2017
> New Revision: 315834
> URL: https://svnweb.freebsd.org/changeset/base/315834
> 
> Log:
>   MFC r314913: MFV r314911: 7867 ARC space accounting leak

Thanks!
Now hit ratio regression?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r313450 - in stable/11: lib/libc/gen lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys

[Slawa Olhovchenkov]

On Tue, Mar 21, 2017 at 08:05:31PM -0700, John Baldwin wrote:

> On Wednesday, March 15, 2017 05:30:53 PM Slawa Olhovchenkov wrote:
> > On Wed, Feb 08, 2017 at 06:32:35PM +, John Baldwin wrote:
> > 
> > > Author: jhb
> > > Date: Wed Feb  8 18:32:35 2017
> > > New Revision: 313450
> > > URL: https://svnweb.freebsd.org/changeset/base/313450
> > > 
> > > Log:
> > >   MFC 310638:
> > >   Rename the 'flags' argument to getfsstat() to 'mode' and validate it.
> > >   
> > >   This argument is not a bitmask of flags, but only accepts a single 
> > > value.
> > >   Fail with EINVAL if an invalid value is passed to 'flag'.  Rename the
> > >   'flags' argument to getmntinfo(3) to 'mode' as well to match.
> > >   
> > >   This is a followup to r308088.
> > 
> > >  kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize,
> > > -size_t *countp, enum uio_seg bufseg, int flags)
> > > +size_t *countp, enum uio_seg bufseg, int mode)
> > >  {
> > >   struct mount *mp, *nmp;
> > >   struct statfs *sfsp, *sp, *sptmp, *tofree;
> > >   size_t count, maxcount;
> > >   int error;
> > >  
> > > + switch (mode) {
> > > + case MNT_WAIT:
> > > + case MNT_NOWAIT:
> > > + break;
> > > + default:
> > > + return (EINVAL);
> > > + }
> > >  restart:
> > 
> > This is break net-snmp UCD-SNMP-MIB::dskTable oid:
> > 
> >  82434 snmpdCALL  getfsstat(0,0,

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Slawa Olhovchenkov]

On Tue, Mar 21, 2017 at 01:40:22PM -0700, Gleb Smirnoff wrote:

> On Tue, Mar 21, 2017 at 10:52:02PM +0300, Slawa Olhovchenkov wrote:
> S> > On Tue, Mar 21, 2017 at 10:40:34AM -0700, John Baldwin wrote:
> S> > J> First, this is a very good change and long overdue in divorcing the
> S> > J> user-facing structure for live system reporting vs the kernel 
> structure.
> S> > J> 
> S> > J> However, I realize you don't use info from netstat when debugging 
> kernel
> S> > J> crash dumps, but other people _do_.  It's ok if the kvm bits of 
> netstat
> S> > J> require a matching kernel and thus require recompiling everytime the 
> ABI
> S> > J> changes, but it is useful to have them.  Please restore those.
> S> > 
> S> > I have very much anticipated this comment from you, John.
> S> > 
> S> > I would like to remind you, that we have had this very exact conversation
> S> > back when I removed kvm support from netstat/route.c. Let me search the
> S> > archives:
> S> > 
> S> > https://lists.freebsd.org/pipermail/svn-src-head/2015-April/070480.html
> S> > 
> S> > This conversation has had a continuation on IRC, which I don't archive.
> S> > 
> S> > AFAIR, first I told that with all my involvement into networking stack,
> S> > I never ever had experienced a need to run route stats on a core. The
> S> > debugger were the only useful tool. And that opinion was seconded by
> S> > other network hackers. Then we discussed that a proper tool chould use
> S> > dynamic type parsing and not kvm(3). You said that future gdb has python
> S> > scripting and that would work fine. Meanwhile, you insisted that I 
> restore
> S> > the functionality. I resisted to put kvm(3) back into netstat/route.c, 
> and
> S> > instead I created a gdb script that prints exactly what 'nestat -anr -M 
> core'
> S> > prints. And I committed the script just to satisfy your demand:
> S> > 
> S> > tools/debugscripts/netstat-anr.gdb
> S> > 
> S> > Can you please fairly answer, have you (or anyone else) ever used the
> S> > script during these 2 years?
> S> > 
> S> > I believe, the inpcb/tcpcb printing from a core functionality has the
> S> > same level of real usefulness. I could create the same script for pcbs,
> S> > and I am afraid it is going to share fate of netstat-anr.gdb.
> S> 
> S> How long run this script for core file w/ 40K TCP connections?
> 
> You tell me. When I analyze cores, I don't read through 40K TCP connections.

Real, frech core:

# grep netstat /var/crash/core.txt.3
netstat -s
netstat -m
netstat: memstat_kvm_all: invalid address (0x0)
netstat -anA
netstat -aL
# grep -c tcp4 /var/crash/core.txt.3
38172

This created automaticly at reboot and boot paused until core.txt
created.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Slawa Olhovchenkov]

On Tue, Mar 21, 2017 at 01:07:42PM -0700, Cy Schubert wrote:

> In message <20170321195202.gf86...@zxy.spb.ru>, Slawa Olhovchenkov writes:
> > On Tue, Mar 21, 2017 at 11:50:04AM -0700, Gleb Smirnoff wrote:
> > 
> > >   John,
> > > 
> > > On Tue, Mar 21, 2017 at 10:40:34AM -0700, John Baldwin wrote:
> > > J> First, this is a very good change and long overdue in divorcing the
> > > J> user-facing structure for live system reporting vs the kernel 
> > > structure.
> > > J> 
> > > J> However, I realize you don't use info from netstat when debugging 
> > > kernel
> > > J> crash dumps, but other people _do_.  It's ok if the kvm bits of netstat
> > > J> require a matching kernel and thus require recompiling everytime the 
> > > ABI
> > > J> changes, but it is useful to have them.  Please restore those.
> > > 
> > > I have very much anticipated this comment from you, John.
> > > 
> > > I would like to remind you, that we have had this very exact conversation
> > > back when I removed kvm support from netstat/route.c. Let me search the
> > > archives:
> > > 
> > > https://lists.freebsd.org/pipermail/svn-src-head/2015-April/070480.html
> > > 
> > > This conversation has had a continuation on IRC, which I don't archive.
> > > 
> > > AFAIR, first I told that with all my involvement into networking stack,
> > > I never ever had experienced a need to run route stats on a core. The
> > > debugger were the only useful tool. And that opinion was seconded by
> > > other network hackers. Then we discussed that a proper tool chould use
> > > dynamic type parsing and not kvm(3). You said that future gdb has python
> > > scripting and that would work fine. Meanwhile, you insisted that I restore
> > > the functionality. I resisted to put kvm(3) back into netstat/route.c, and
> > > instead I created a gdb script that prints exactly what 'nestat -anr -M 
> > > cor
> > e'
> > > prints. And I committed the script just to satisfy your demand:
> > > 
> > > tools/debugscripts/netstat-anr.gdb
> > > 
> > > Can you please fairly answer, have you (or anyone else) ever used the
> > > script during these 2 years?
> > > 
> > > I believe, the inpcb/tcpcb printing from a core functionality has the
> > > same level of real usefulness. I could create the same script for pcbs,
> > > and I am afraid it is going to share fate of netstat-anr.gdb.
> > 
> > How long run this script for core file w/ 40K TCP connections?
> 
> Would it be possible to replace this script with new DTrace probes and a 
> DTrace script?

DTrace probes in /etc/rc.d/savecore? Realy?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315662 - in head: contrib/bsnmp/snmp_mibII contrib/ipfilter/ipsend lib/libprocstat sys/netinet sys/sys usr.bin/netstat usr.bin/sockstat usr.bin/systat usr.sbin/tcpdrop usr.sbin/trpt

[Slawa Olhovchenkov]

On Tue, Mar 21, 2017 at 11:50:04AM -0700, Gleb Smirnoff wrote:

>   John,
> 
> On Tue, Mar 21, 2017 at 10:40:34AM -0700, John Baldwin wrote:
> J> First, this is a very good change and long overdue in divorcing the
> J> user-facing structure for live system reporting vs the kernel structure.
> J> 
> J> However, I realize you don't use info from netstat when debugging kernel
> J> crash dumps, but other people _do_.  It's ok if the kvm bits of netstat
> J> require a matching kernel and thus require recompiling everytime the ABI
> J> changes, but it is useful to have them.  Please restore those.
> 
> I have very much anticipated this comment from you, John.
> 
> I would like to remind you, that we have had this very exact conversation
> back when I removed kvm support from netstat/route.c. Let me search the
> archives:
> 
> https://lists.freebsd.org/pipermail/svn-src-head/2015-April/070480.html
> 
> This conversation has had a continuation on IRC, which I don't archive.
> 
> AFAIR, first I told that with all my involvement into networking stack,
> I never ever had experienced a need to run route stats on a core. The
> debugger were the only useful tool. And that opinion was seconded by
> other network hackers. Then we discussed that a proper tool chould use
> dynamic type parsing and not kvm(3). You said that future gdb has python
> scripting and that would work fine. Meanwhile, you insisted that I restore
> the functionality. I resisted to put kvm(3) back into netstat/route.c, and
> instead I created a gdb script that prints exactly what 'nestat -anr -M core'
> prints. And I committed the script just to satisfy your demand:
> 
> tools/debugscripts/netstat-anr.gdb
> 
> Can you please fairly answer, have you (or anyone else) ever used the
> script during these 2 years?
> 
> I believe, the inpcb/tcpcb printing from a core functionality has the
> same level of real usefulness. I could create the same script for pcbs,
> and I am afraid it is going to share fate of netstat-anr.gdb.

How long run this script for core file w/ 40K TCP connections?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315653 - in head: lib/libstand sys/boot/common sys/boot/i386/libi386

[Slawa Olhovchenkov]

On Tue, Mar 21, 2017 at 05:53:12PM +0200, Toomas Soome wrote:

> 
> > On 21. märts 2017, at 17:15, Ian Lepore <i...@freebsd.org> wrote:
> > 
> > On Tue, 2017-03-21 at 15:35 +0300, Slawa Olhovchenkov wrote:
> >> On Mon, Mar 20, 2017 at 10:20:17PM +, Toomas Soome wrote:
> >> 
> >>> 
> >>> Author: tsoome
> >>> Date: Mon Mar 20 22:20:17 2017
> >>> New Revision: 315653
> >>> URL: https://svnweb.freebsd.org/changeset/base/315653
> >>> 
> >>> Log:
> >>>   loader: verify the value from dhcp.interface-mtu and use snprintf
> >>> to set mtu
> >>>   
> >>>   Since the uset can set dhcp.interface-mtu, we need to try to
> >>> validate the
> >>>   value. So we verify if the conversion to int is successful and we
> >>> will not
> >>>   allow to set value greater than max IPv4 packet size.
> >>>   
> >>> + tmp > USHRT_MAX) {
> >>> + printf("%s: bad value:
> >>> \"%s\", "
> >>> + "ignoring\n",
> >>> + "dhcp.interface-mtu",
> >>> val);
> >> ===
> >> USHRT_MAX  Maximum value for an object of type unsigned short
> >> int
> >> 65535 (216-1) or greater*
> >> 
> >> * the actual value depends on the particular system and library
> >> implementation, but shall reflect the limits of these types in the
> >> target platform.
> >> ===
> >> 
> >> I mean IF_MAXMTU more correct.
> >> 
> > 
> > The context here is libstand; because it is standalone by design, the
> > code doesn't have access to IF_MAXMTU or other kernel/userland
> > constants.  There is also no question that a short is 16 bits or that
> > USHRT_MAX will be anything other than 65535 in that environment.  If
> > some platform did appear that had a different-sized short by default,
> > we would add whatever flags are necessary to force it back to 16 bits
> > in src/share/mk/bsd.stand.mk.
> > 
> 
> 
> Also note the “upper” value is entirely fictional - we felt we need to pick 
> some “sane” default, with current (common 1Gb/s) ethernet hardware you will 
> be in trouble long before reaching that value;)

18000?
IMHO, max found in different spec is about 16K.
Mostly jumbo is 9000-9198.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r315653 - in head: lib/libstand sys/boot/common sys/boot/i386/libi386

[Slawa Olhovchenkov]

On Mon, Mar 20, 2017 at 10:20:17PM +, Toomas Soome wrote:

> Author: tsoome
> Date: Mon Mar 20 22:20:17 2017
> New Revision: 315653
> URL: https://svnweb.freebsd.org/changeset/base/315653
> 
> Log:
>   loader: verify the value from dhcp.interface-mtu and use snprintf to set mtu
>   
>   Since the uset can set dhcp.interface-mtu, we need to try to validate the
>   value. So we verify if the conversion to int is successful and we will not
>   allow to set value greater than max IPv4 packet size.
>   
> + tmp > USHRT_MAX) {
> + printf("%s: bad value: \"%s\", "
> + "ignoring\n",
> + "dhcp.interface-mtu", val);

===
USHRT_MAX   Maximum value for an object of type unsigned short int
65535 (216-1) or greater*

* the actual value depends on the particular system and library
implementation, but shall reflect the limits of these types in the
target platform.
===

I mean IF_MAXMTU more correct.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r313450 - in stable/11: lib/libc/gen lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys

[Slawa Olhovchenkov]

On Wed, Feb 08, 2017 at 06:32:35PM +, John Baldwin wrote:

> Author: jhb
> Date: Wed Feb  8 18:32:35 2017
> New Revision: 313450
> URL: https://svnweb.freebsd.org/changeset/base/313450
> 
> Log:
>   MFC 310638:
>   Rename the 'flags' argument to getfsstat() to 'mode' and validate it.
>   
>   This argument is not a bitmask of flags, but only accepts a single value.
>   Fail with EINVAL if an invalid value is passed to 'flag'.  Rename the
>   'flags' argument to getmntinfo(3) to 'mode' as well to match.
>   
>   This is a followup to r308088.

>  kern_getfsstat(struct thread *td, struct statfs **buf, size_t bufsize,
> -size_t *countp, enum uio_seg bufseg, int flags)
> +size_t *countp, enum uio_seg bufseg, int mode)
>  {
>   struct mount *mp, *nmp;
>   struct statfs *sfsp, *sp, *sptmp, *tofree;
>   size_t count, maxcount;
>   int error;
>  
> + switch (mode) {
> + case MNT_WAIT:
> + case MNT_NOWAIT:
> + break;
> + default:
> + return (EINVAL);
> + }
>  restart:

This is break net-snmp UCD-SNMP-MIB::dskTable oid:

 82434 snmpdCALL  

Re: svn commit: r314274 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Slawa Olhovchenkov]

On Tue, Mar 07, 2017 at 11:36:34AM +0200, Andriy Gapon wrote:

> On 07/03/2017 11:29, Slawa Olhovchenkov wrote:
> > You are kidding?! How to work this commit w/o r307265?
> > r307265 is l2arc compression suport (buggly).
> > this commit fix l2arc part.
> > arc part still buggly.
> > 
> > hmm, may be I am not clean, I am not rever ALL to r307265. I am rever
> > exact r307265 and 314274. This is like bisect by one try.
> 
> I am not sure what you are saying...
> Do you see the problem with just r307265?
> Or with r307265 + r314274 ?

r307265 + r314274
Don't try r307265 (by bad feedbacks).
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r314274 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Slawa Olhovchenkov]

On Tue, Mar 07, 2017 at 11:24:42AM +0200, Andriy Gapon wrote:

> On 07/03/2017 11:18, Slawa Olhovchenkov wrote:
> > On Tue, Mar 07, 2017 at 11:02:46AM +0200, Andriy Gapon wrote:
> > 
> >> On 07/03/2017 05:53, Slawa Olhovchenkov wrote:
> >>> On Sat, Feb 25, 2017 at 05:03:49PM +, Andriy Gapon wrote:
> >>>
> >>>> Author: avg
> >>>> Date: Sat Feb 25 17:03:48 2017
> >>>> New Revision: 314274
> >>>> URL: https://svnweb.freebsd.org/changeset/base/314274
> >>>>
> >>>> Log:
> >>>>   l2arc: try to fix write size calculation broken by Compressed ARC 
> >>>> commit
> >>>>   
> >>>>   While there, make a change to not evict a first buffer outside the
> >>>>   requested eviciton range.
> >>>>   
> >>>>   To do:
> >>>>   - give more consistent names to the size variables
> >>>>   - upstream to OpenZFS
> >>>
> >>> Mem: 6647M Active, 8399M Inact, 87G Wired, 49K Buf, 23G Free
> >>> ^
> >>> ARC: 130G Total, 255M MFU, 80G MRU, 267M Anon, 72M Header, 41M Other
> >>>  ^
> >>>
> >>> 128GB phys mem
> >>>
> >>
> >> Why this commit?
> > 
> > revert this commit and r307265 resolve this.
> > i.e. may be r307265, but r307265 related to this.
> 
> So, why not comment on r307265 or bisect first?

You are kidding?! How to work this commit w/o r307265?
r307265 is l2arc compression suport (buggly).
this commit fix l2arc part.
arc part still buggly.

hmm, may be I am not clean, I am not rever ALL to r307265. I am rever
exact r307265 and 314274. This is like bisect by one try.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r314274 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Slawa Olhovchenkov]

On Tue, Mar 07, 2017 at 11:02:46AM +0200, Andriy Gapon wrote:

> On 07/03/2017 05:53, Slawa Olhovchenkov wrote:
> > On Sat, Feb 25, 2017 at 05:03:49PM +, Andriy Gapon wrote:
> > 
> >> Author: avg
> >> Date: Sat Feb 25 17:03:48 2017
> >> New Revision: 314274
> >> URL: https://svnweb.freebsd.org/changeset/base/314274
> >>
> >> Log:
> >>   l2arc: try to fix write size calculation broken by Compressed ARC commit
> >>   
> >>   While there, make a change to not evict a first buffer outside the
> >>   requested eviciton range.
> >>   
> >>   To do:
> >>   - give more consistent names to the size variables
> >>   - upstream to OpenZFS
> > 
> > Mem: 6647M Active, 8399M Inact, 87G Wired, 49K Buf, 23G Free
> > ^
> > ARC: 130G Total, 255M MFU, 80G MRU, 267M Anon, 72M Header, 41M Other
> >  ^
> > 
> > 128GB phys mem
> > 
> 
> Why this commit?

revert this commit and r307265 resolve this.
i.e. may be r307265, but r307265 related to this.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r314274 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs

[Slawa Olhovchenkov]

On Sat, Feb 25, 2017 at 05:03:49PM +, Andriy Gapon wrote:

> Author: avg
> Date: Sat Feb 25 17:03:48 2017
> New Revision: 314274
> URL: https://svnweb.freebsd.org/changeset/base/314274
> 
> Log:
>   l2arc: try to fix write size calculation broken by Compressed ARC commit
>   
>   While there, make a change to not evict a first buffer outside the
>   requested eviciton range.
>   
>   To do:
>   - give more consistent names to the size variables
>   - upstream to OpenZFS

Mem: 6647M Active, 8399M Inact, 87G Wired, 49K Buf, 23G Free
^
ARC: 130G Total, 255M MFU, 80G MRU, 267M Anon, 72M Header, 41M Other
 ^

128GB phys mem
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r314669 - head/sys/i386/conf

[Slawa Olhovchenkov]

On Sat, Mar 04, 2017 at 03:04:17PM +, Pedro F. Giffuni wrote:

> Author: pfg
> Date: Sat Mar  4 15:04:17 2017
> New Revision: 314669
> URL: https://svnweb.freebsd.org/changeset/base/314669
> 
> Log:
>   Drop i486 from the default i386 GENERIC kernel configuration.
>   
>   80486 production was stopped by Intel on September 2007. Dropping the 486
>   configuration option from the GENERIC kernel improves performance
>   slightly.
>   
>   Removing I486_CPU is consistent at this time: we don't support any
>   processor without a FPU and the PC-98 arch, which frequently involved i486
>   CPUs, is also gone so we don't test such platforms anymore.

What is realy mean?
Some Via CPU is like i486 (by instruction set).

CPU: VIA Ezra (800.04-MHz 686-class CPU)
  Origin="CentaurHauls"  Id=0x678  Family=0x6  Model=0x7  Stepping=8
  Features=0x803035
  AMD Features=0x8000<3DNow!>

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r314036 - head/usr.sbin/bsdinstall/scripts

[Slawa Olhovchenkov]

On Wed, Feb 22, 2017 at 10:13:41AM -0800, Conrad Meyer wrote:

> On Wed, Feb 22, 2017 at 10:05 AM, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> > On Wed, Feb 22, 2017 at 08:11:14AM -0800, Conrad Meyer wrote:
> >
> >> On Wed, Feb 22, 2017 at 3:23 AM, Joel Dahl <j...@vnode.se> wrote:
> >> > On Wed, Feb 22, 2017 at 07:56:52AM +, Bartłomiej Rutkowski wrote:
> >> >> I strongly believe we should, by default, ship as secured and hardened 
> >> >> as
> >> >> possible in order to improve overall security of new users 
> >> >> installations.
> >> >> Power users will and do change the OS as they please, they most likely
> >> >> don't use bsdinstall in first place, so they're not affected in any way.
> >> >
> >> > Sorry, I strongly disagree with that. I'm most likely a "power user" and 
> >> > I use
> >> > bsdinstall.
> >>
> >> Ditto.  I'm also unfamiliar enough with the installer to trip on this
> >> kind of thing.  Slawa's proposed "disable all" option would be fine.
> >
> > My english not enought fluent for more explicate proposal, from my
> > point most of this options do hardened in only limited cases, for
> > other cases same options do system more un-hardened by force working
> > as root. Some have unevident effects (/tmp cleaning, for example).
> 
> Yep.  I am not concerned about disabling sendmail or remote syslog by
> default, though.

Also, what mean by 'disabling remote syslog'?
As I know syslogd by default don't collect remote messages and need -a
options. May be this is about -s options? How many -s? Not clean.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r314036 - head/usr.sbin/bsdinstall/scripts

[Slawa Olhovchenkov]

On Wed, Feb 22, 2017 at 08:11:14AM -0800, Conrad Meyer wrote:

> On Wed, Feb 22, 2017 at 3:23 AM, Joel Dahl  wrote:
> > On Wed, Feb 22, 2017 at 07:56:52AM +, Bartłomiej Rutkowski wrote:
> >> I strongly believe we should, by default, ship as secured and hardened as
> >> possible in order to improve overall security of new users installations.
> >> Power users will and do change the OS as they please, they most likely
> >> don't use bsdinstall in first place, so they're not affected in any way.
> >
> > Sorry, I strongly disagree with that. I'm most likely a "power user" and I 
> > use
> > bsdinstall.
> 
> Ditto.  I'm also unfamiliar enough with the installer to trip on this
> kind of thing.  Slawa's proposed "disable all" option would be fine.

My english not enought fluent for more explicate proposal, from my
point most of this options do hardened in only limited cases, for
other cases same options do system more un-hardened by force working
as root. Some have unevident effects (/tmp cleaning, for example).

For many users this options will be source of weird issuses (gdb don't
work? fucking ugly freebsd! migrate to linux).

This is evil trend of enforcing weird solutions under the auspices of
'my safety': airport security check, backgound check on every point,
lawfull intercept, block access to hardware management in safety
enviroment by 'leak ecnription'. I am enoght smart for self-sufficient
security risk assessment!

Industry already have at some "hardened" BSD: OpenBSD and HardenedBSD.
Waht about market share?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r314036 - head/usr.sbin/bsdinstall/scripts

[Slawa Olhovchenkov]

On Tue, Feb 21, 2017 at 09:37:34AM +, Bartek Rutkowski wrote:

> Author: robak (ports committer)
> Date: Tue Feb 21 09:37:33 2017
> New Revision: 314036
> URL: https://svnweb.freebsd.org/changeset/base/314036
> 
> Log:
>   Enable bsdinstall hardening options by default.
>   
>   As discussed previously, in order to introduce new OS hardening
>   defaults, we've added them to bsdinstall in 'off by default' mode.
>   It has been there for a while, so the next step is to change them
>   to 'on by defaul' mode, so that in future we could simply enable
>   them in base OS.

Please include option "disable all" for simple disable all.

>   Reviewed by:brd
>   Approved by:adrian
>   Differential Revision:  https://reviews.freebsd.org/D9641
> 
> Modified:
>   head/usr.sbin/bsdinstall/scripts/hardening
> 
> Modified: head/usr.sbin/bsdinstall/scripts/hardening
> ==
> --- head/usr.sbin/bsdinstall/scripts/hardeningTue Feb 21 09:33:21 
> 2017(r314035)
> +++ head/usr.sbin/bsdinstall/scripts/hardeningTue Feb 21 09:37:33 
> 2017(r314036)
> @@ -36,15 +36,15 @@ FEATURES=$( dialog --backtitle "FreeBSD 
>  --title "System Hardening" --nocancel --separate-output \
>  --checklist "Choose system security hardening options:" \
>  0 0 0 \
> - "0 hide_uids" "Hide processes running as other users" ${hide_uids:-off} 
> \
> - "1 hide_gids" "Hide processes running as other groups" 
> ${hide_gids:-off} \
> - "2 read_msgbuf" "Disable reading kernel message buffer for unprivileged 
> users" ${read_msgbuf:-off} \
> - "3 proc_debug" "Disable process debugging facilities for unprivileged 
> users" ${proc_debug:-off} \
> - "4 random_pid" "Randomize the PID of newly created processes" 
> ${random_pid:-off} \
> - "5 stack_guard" "Insert stack guard page ahead of the growable 
> segments" ${stack_guard:-off} \
> - "6 clear_tmp" "Clean the /tmp filesystem on system startup" 
> ${clear_tmp:-off} \
> - "7 disable_syslogd" "Disable opening Syslogd network socket (disables 
> remote logging)" ${disable_syslogd:-off} \
> - "8 disable_sendmail" "Disable Sendmail service" 
> ${disable_sendmail:-off} \
> + "0 hide_uids" "Hide processes running as other users" ${hide_uids:-on} \
> + "1 hide_gids" "Hide processes running as other groups" ${hide_gids:-on} 
> \
> + "2 read_msgbuf" "Disable reading kernel message buffer for unprivileged 
> users" ${read_msgbuf:-on} \
> + "3 proc_debug" "Disable process debugging facilities for unprivileged 
> users" ${proc_debug:-on} \
> + "4 random_pid" "Randomize the PID of newly created processes" 
> ${random_pid:-on} \
> + "5 stack_guard" "Insert stack guard page ahead of the growable 
> segments" ${stack_guard:-on} \
> + "6 clear_tmp" "Clean the /tmp filesystem on system startup" 
> ${clear_tmp:-on} \
> + "7 disable_syslogd" "Disable opening Syslogd network socket (disables 
> remote logging)" ${disable_syslogd:-on} \
> + "8 disable_sendmail" "Disable Sendmail service" ${disable_sendmail:-on} 
> \
>  2>&1 1>&3 )
>  exec 3>&-
>  
> ___
> svn-src-all@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r313330 - in head: contrib/netcat lib/libipsec sbin/ifconfig sbin/setkey share/man/man4 sys/conf sys/modules sys/modules/ipsec sys/modules/tcp/tcpmd5 sys/net sys/netinet sys/netinet/tc

[Slawa Olhovchenkov]

On Tue, Feb 07, 2017 at 03:53:05AM +0300, Andrey V. Elsukov wrote:

> On 06.02.2017 17:31, Dmitry Morozovsky wrote:
> >> Date: Mon Feb  6 08:49:57 2017
> >> New Revision: 313330
> >> URL: https://svnweb.freebsd.org/changeset/base/313330
> >>
> >> Log:
> >>   Merge projects/ipsec into head/.
> >
> > [snip]
> >
> > Great, thanks!
> >
> > Have you any plans to merge this into stable/11 to reduce diffs in network
> > stack code?
> 
> It depends from the further users feedback.
> I wanted to do MFC after one or two months. But there are two things 
> that are questionable. The date of stable/11 feature freeze is not 
> known. And there is also some changes that can be considered as POLA 
> violations. E.g. now SPIs are unique, and if user had manually 
> configured SAs with the same SPI, the MFC will break this.

What about IKE? I am don't know, do IKE SPI number negotiation?
Or remote side just assign implicit SPI? In last case posible race on
local system.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r313318 - in head: share/man/man4 sys/dev/cxgbe

[Slawa Olhovchenkov]

On Mon, Feb 06, 2017 at 05:19:30AM +, Navdeep Parhar wrote:

> Author: np
> Date: Mon Feb  6 05:19:29 2017
> New Revision: 313318
> URL: https://svnweb.freebsd.org/changeset/base/313318
> 
> Log:
>   cxgbe(4):  Allow tunables that control the number of queues to be set to
>   '-n' to tell the driver to create _up to_ 'n' queues if enough cores are
>   available.  For example, setting hw.cxgbe.nrxq10g="-32" will result in
>   16 queues if the system has 16 cores, 32 if it has 32.
>   
>   There is no change in the default number of queues of any type.

Just for my info: how many queues supported by different hardware (T4/T5/T6)?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r313275 - in head/sys: kern sys

[Slawa Olhovchenkov]

On Sun, Feb 05, 2017 at 11:01:28AM +0100, Mateusz Guzik wrote:

> On Sun, Feb 05, 2017 at 01:00:11PM +0300, Slawa Olhovchenkov wrote:
> > On Sun, Feb 05, 2017 at 08:04:12AM +, Mateusz Guzik wrote:
> > 
> > > Author: mjg
> > > Date: Sun Feb  5 08:04:11 2017
> > > New Revision: 313275
> > > URL: https://svnweb.freebsd.org/changeset/base/313275
> > > 
> > > Log:
> > >   mtx: move lockstat handling out of inline primitives
> > >   
> > >   Lockstat requires checking if it is enabled and if so, calling a 6 
> > > argument
> > >   function. Further, determining whether to call it on unlock requires
> > >   pre-reading the lock value.
> > >   
> > >   This is problematic in at least 3 ways:
> > >   - more branches in the hot path than necessary
> > >   - additional cacheline ping pong under contention
> > >   - bigger code
> > >   
> > >   Instead, check first if lockstat handling is necessary and if so, just 
> > > fall
> > >   back to regular locking routines. For this purpose a new macro is 
> > > introduced
> > >   (LOCKSTAT_PROFILE_ENABLED).
> > >   
> > >   LOCK_PROFILING uninlines all primitives. Fold in the current inline lock
> > >   variant into the _mtx_lock_flags to retain the support. With this change
> > >   the inline variants are not used when LOCK_PROFILING is defined and thus
> > >   can ignore its existence.
> > >   
> > >   This results in:
> > >  textdata bss dec hex filename
> > >   222596671303208 4994976 285578511b3c21b kernel.orig
> > >   217973151303208 4994976 280954991acb40b kernel.patched
> > >   
> > >   i.e. about 3% reduction in text size.
> > >   
> > >   A remaining action is to remove spurious arguments for internal kernel
> > >   consumers.
> > 
> > Do you planed MFC all of this?
> 
> Yes, around march.

Thanks!
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r313275 - in head/sys: kern sys

[Slawa Olhovchenkov]

On Sun, Feb 05, 2017 at 08:04:12AM +, Mateusz Guzik wrote:

> Author: mjg
> Date: Sun Feb  5 08:04:11 2017
> New Revision: 313275
> URL: https://svnweb.freebsd.org/changeset/base/313275
> 
> Log:
>   mtx: move lockstat handling out of inline primitives
>   
>   Lockstat requires checking if it is enabled and if so, calling a 6 argument
>   function. Further, determining whether to call it on unlock requires
>   pre-reading the lock value.
>   
>   This is problematic in at least 3 ways:
>   - more branches in the hot path than necessary
>   - additional cacheline ping pong under contention
>   - bigger code
>   
>   Instead, check first if lockstat handling is necessary and if so, just fall
>   back to regular locking routines. For this purpose a new macro is introduced
>   (LOCKSTAT_PROFILE_ENABLED).
>   
>   LOCK_PROFILING uninlines all primitives. Fold in the current inline lock
>   variant into the _mtx_lock_flags to retain the support. With this change
>   the inline variants are not used when LOCK_PROFILING is defined and thus
>   can ignore its existence.
>   
>   This results in:
>  textdata bss dec hex filename
>   222596671303208 4994976 285578511b3c21b kernel.orig
>   217973151303208 4994976 280954991acb40b kernel.patched
>   
>   i.e. about 3% reduction in text size.
>   
>   A remaining action is to remove spurious arguments for internal kernel
>   consumers.

Do you planed MFC all of this?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r312910 - in head: . etc/etc.pc98 etc/rc.d lib/libsysdecode libexec release release/doc release/doc/en_US.ISO8859-1/hardware release/doc/en_US.ISO8859-1/readme release/doc/share/exampl

[Slawa Olhovchenkov]

On Wed, Feb 01, 2017 at 10:56:24AM -0700, Warner Losh wrote:

> >> > > Fair enough.  I haven't fully put away my 12 axe and am toying with
> >> > > dropping any ISA-only storage and NIC drivers (and perhaps pccard-only
> >> > > as well in that case).  Hardware that wants to use ISA/pccard for
> >> > > storage is probably happier running 4.x anyway.  One question is if we
> >> > > should drop ISA attachments in that case for drivers that support PCI
> >> > > and ISA.  However, there's a fair list of ISA-only adapters that would
> >> > > be a good place to start anyway.  One concern is to not drop any 
> >> > > drivers
> >> >
> >> > ps/2 keyboard, mouse, touchpads, lm sensors, etc?...
> >>
> >> Those aren't storage or NICs.  There are many "legacy" device still present
> >> in modern systems that we obviously have to support.  However, if you have
> >> an ISA Adapter SCSI HBA in an ISA slot, the machine running that is 
> >> probably
> >> happier running 4.x than 12.0.
> >
> > My be I am missread, I think removed ISA bus and all devices attached
> > to ISA bus.
> 
> We will never ever ever remove the ISA bus on the i386 or amd64 ports.
> That's simply not possible due to the legacy busses and the fact that
> many devices are logically attached to the address space used by the
> ISA bus even if there aren't physical plastic ISA slots.

Ah, sorry, this is my missread.
I am don't have any ISA cards in use many years.
Only some ISA COM/LPT/sound cards in far-away box.

PS: again, may be time to move all drivers to modules and load all
GENERIC's devices from loader.conf? /boot/loader have good performance
now.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r312910 - in head: . etc/etc.pc98 etc/rc.d lib/libsysdecode libexec release release/doc release/doc/en_US.ISO8859-1/hardware release/doc/en_US.ISO8859-1/readme release/doc/share/exampl

[Slawa Olhovchenkov]

On Wed, Feb 01, 2017 at 01:45:14PM -0800, John Baldwin wrote:

> On Wednesday, February 01, 2017 03:39:57 PM Mark Linimon wrote:
> > On Wed, Feb 01, 2017 at 08:09:50PM +0300, Slawa Olhovchenkov wrote:
> > > Also, I am think current ports don't build on 4.x.
> > 
> > I will personally guarantee, in writing, that current ports do not build
> > on 4.x, nor have they done so for years.  I personally removed the legacy
> > cruft when 4.11 finally went EOL.
> > 
> > > I am got complains about using ports on 8.x.
> > 
> > I am 99% certain that ports will not work on either 8.x or 9.x.  Legacy
> > cruft was removed at the EOL in each of those cases.
> > 
> > Anyone who think that we can support ports on 4.x, 5.x, 6.x, 7.x, 8.x,
> > 9.x, 10.x, 11.x, and -current, all at the same time, needs to seek medical
> > attention at once.  At the absolute least, that era spans 3 major versions
> > of make(1) and two completely different package implementations.
> 
> I think Slawa's point was that my suggestion that people with old hardware
> should run old releases means that they cannot use a modern ports checkout

Yes.

> with those older systems.  That point is correct, but you probably don't
> want to run newer, more bloated 3rd party software on such gear either.

Not all software bloated, some software need to updated (for example, not sure
about sshd in 4.x system. Or openssl).
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r312910 - in head: . etc/etc.pc98 etc/rc.d lib/libsysdecode libexec release release/doc release/doc/en_US.ISO8859-1/hardware release/doc/en_US.ISO8859-1/readme release/doc/share/exampl

[Slawa Olhovchenkov]

On Wed, Feb 01, 2017 at 03:39:57PM -0600, Mark Linimon wrote:

> On Wed, Feb 01, 2017 at 08:09:50PM +0300, Slawa Olhovchenkov wrote:
> > Also, I am think current ports don't build on 4.x.
> 
> I will personally guarantee, in writing, that current ports do not build
> on 4.x, nor have they done so for years.  I personally removed the legacy
> cruft when 4.11 finally went EOL.
> 
> > I am got complains about using ports on 8.x.
> 
> I am 99% certain that ports will not work on either 8.x or 9.x.  Legacy
> cruft was removed at the EOL in each of those cases.
> 
> Anyone who think that we can support ports on 4.x, 5.x, 6.x, 7.x, 8.x,
> 9.x, 10.x, 11.x, and -current, all at the same time, needs to seek medical
> attention at once.  At the absolute least, that era spans 3 major versions
> of make(1) and two completely different package implementations.

I am assume no problem to use new make on old system.
May be posible use pkg too (not sure about pkg requirements to
syscalls).
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r312910 - in head: . etc/etc.pc98 etc/rc.d lib/libsysdecode libexec release release/doc release/doc/en_US.ISO8859-1/hardware release/doc/en_US.ISO8859-1/readme release/doc/share/exampl

[Slawa Olhovchenkov]

On Wed, Feb 01, 2017 at 08:59:40AM -0800, John Baldwin wrote:

> > > Fair enough.  I haven't fully put away my 12 axe and am toying with
> > > dropping any ISA-only storage and NIC drivers (and perhaps pccard-only
> > > as well in that case).  Hardware that wants to use ISA/pccard for
> > > storage is probably happier running 4.x anyway.  One question is if we
> > > should drop ISA attachments in that case for drivers that support PCI
> > > and ISA.  However, there's a fair list of ISA-only adapters that would
> > > be a good place to start anyway.  One concern is to not drop any drivers
> > 
> > ps/2 keyboard, mouse, touchpads, lm sensors, etc?...
> 
> Those aren't storage or NICs.  There are many "legacy" device still present
> in modern systems that we obviously have to support.  However, if you have
> an ISA Adapter SCSI HBA in an ISA slot, the machine running that is probably
> happier running 4.x than 12.0.

Also, I am think current ports don't build on 4.x.
I am got complains about using ports on 8.x.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r312910 - in head: . etc/etc.pc98 etc/rc.d lib/libsysdecode libexec release release/doc release/doc/en_US.ISO8859-1/hardware release/doc/en_US.ISO8859-1/readme release/doc/share/exampl

[Slawa Olhovchenkov]

On Wed, Feb 01, 2017 at 08:59:40AM -0800, John Baldwin wrote:

> On Wednesday, February 01, 2017 01:35:56 PM Slawa Olhovchenkov wrote:
> > On Tue, Jan 31, 2017 at 02:46:23PM -0800, John Baldwin wrote:
> > 
> > > On Tuesday, January 31, 2017 03:33:55 PM Warner Losh wrote:
> > > > On Tue, Jan 31, 2017 at 3:20 PM, John Baldwin <j...@freebsd.org> wrote:
> > > > > On Saturday, January 28, 2017 02:22:15 AM Takahashi Yoshihiro wrote:
> > > > >> Author: nyan
> > > > >> Date: Sat Jan 28 02:22:15 2017
> > > > >> New Revision: 312910
> > > > >> URL: https://svnweb.freebsd.org/changeset/base/312910
> > > > >>
> > > > >> Log:
> > > > >>   Remove pc98 support completely.
> > > > >>   I thank all developers and contributors for pc98.
> > > > >>
> > > > >>   Relnotes:   yes
> > > > >
> > > > > BTW, my impression was that there are some other device drivers
> > > > > that are effectively PC-98 only (e.g. everything that uses scsi_low.c)
> > > > > but they might have pccard attachments for use with PC-98 laptops?
> > > > >
> > > > > Perhaps Warner might know?
> > > > >
> > > > > It seems stg(4) had PCI variants, but nsp(4), ncv(4), and stg(4)
> > > > > all came from NetBSD/pc98 via PAO.
> > > > 
> > > > These all work correctly on any PC Card machine. The only reason they
> > > > came in this way was because these devices were original marketed only
> > > > in Japan. I've used all these cards with external SCSI drives in the
> > > > past.
> > > > 
> > > > As far as I know, only the if_snc driver, which was removed, is truly
> > > > pc98 specific. It is wired in such a way that cannot be used in ibm-at
> > > > compatible laptops.  IIRC, it had hard-wired memory decode lines that
> > > > landed in the middle of the VGA graphics pages or BIOS low memory
> > > > areas. I have one of these cards still, and it will be detected on my
> > > > laptops, but can't work due to the required mappings.
> > > > 
> > > > Now, there's an different question about whether it is time to retire
> > > > some of the now-ancient SCSI cards from the system, but that's a
> > > > different kettle of fish that's larger than just nsp, ncv and stg.
> > > 
> > > Fair enough.  I haven't fully put away my 12 axe and am toying with
> > > dropping any ISA-only storage and NIC drivers (and perhaps pccard-only
> > > as well in that case).  Hardware that wants to use ISA/pccard for
> > > storage is probably happier running 4.x anyway.  One question is if we
> > > should drop ISA attachments in that case for drivers that support PCI
> > > and ISA.  However, there's a fair list of ISA-only adapters that would
> > > be a good place to start anyway.  One concern is to not drop any drivers
> > 
> > ps/2 keyboard, mouse, touchpads, lm sensors, etc?...
> 
> Those aren't storage or NICs.  There are many "legacy" device still present
> in modern systems that we obviously have to support.  However, if you have
> an ISA Adapter SCSI HBA in an ISA slot, the machine running that is probably
> happier running 4.x than 12.0.

My be I am missread, I think removed ISA bus and all devices attached
to ISA bus.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r312910 - in head: . etc/etc.pc98 etc/rc.d lib/libsysdecode libexec release release/doc release/doc/en_US.ISO8859-1/hardware release/doc/en_US.ISO8859-1/readme release/doc/share/exampl

[Slawa Olhovchenkov]

On Tue, Jan 31, 2017 at 02:46:23PM -0800, John Baldwin wrote:

> On Tuesday, January 31, 2017 03:33:55 PM Warner Losh wrote:
> > On Tue, Jan 31, 2017 at 3:20 PM, John Baldwin  wrote:
> > > On Saturday, January 28, 2017 02:22:15 AM Takahashi Yoshihiro wrote:
> > >> Author: nyan
> > >> Date: Sat Jan 28 02:22:15 2017
> > >> New Revision: 312910
> > >> URL: https://svnweb.freebsd.org/changeset/base/312910
> > >>
> > >> Log:
> > >>   Remove pc98 support completely.
> > >>   I thank all developers and contributors for pc98.
> > >>
> > >>   Relnotes:   yes
> > >
> > > BTW, my impression was that there are some other device drivers
> > > that are effectively PC-98 only (e.g. everything that uses scsi_low.c)
> > > but they might have pccard attachments for use with PC-98 laptops?
> > >
> > > Perhaps Warner might know?
> > >
> > > It seems stg(4) had PCI variants, but nsp(4), ncv(4), and stg(4)
> > > all came from NetBSD/pc98 via PAO.
> > 
> > These all work correctly on any PC Card machine. The only reason they
> > came in this way was because these devices were original marketed only
> > in Japan. I've used all these cards with external SCSI drives in the
> > past.
> > 
> > As far as I know, only the if_snc driver, which was removed, is truly
> > pc98 specific. It is wired in such a way that cannot be used in ibm-at
> > compatible laptops.  IIRC, it had hard-wired memory decode lines that
> > landed in the middle of the VGA graphics pages or BIOS low memory
> > areas. I have one of these cards still, and it will be detected on my
> > laptops, but can't work due to the required mappings.
> > 
> > Now, there's an different question about whether it is time to retire
> > some of the now-ancient SCSI cards from the system, but that's a
> > different kettle of fish that's larger than just nsp, ncv and stg.
> 
> Fair enough.  I haven't fully put away my 12 axe and am toying with
> dropping any ISA-only storage and NIC drivers (and perhaps pccard-only
> as well in that case).  Hardware that wants to use ISA/pccard for
> storage is probably happier running 4.x anyway.  One question is if we
> should drop ISA attachments in that case for drivers that support PCI
> and ISA.  However, there's a fair list of ISA-only adapters that would
> be a good place to start anyway.  One concern is to not drop any drivers

ps/2 keyboard, mouse, touchpads, lm sensors, etc?...

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r312437 - in head/sys/dev: mpr mps

[Slawa Olhovchenkov]

On Thu, Jan 19, 2017 at 09:47:51PM +, Scott Long wrote:

> Author: scottl
> Date: Thu Jan 19 21:47:50 2017
> New Revision: 312437
> URL: https://svnweb.freebsd.org/changeset/base/312437
> 
> Log:
>   Rework the debug print API. Event printing no longer gets special handling.
>   All of the printing from the tables file now has wrappers so that the
>   handling is cleaner and it's possible to print something out (say, during
>   development) without having to fight the global debug flags. This re-org
>   will also make it easier to have the tables be compiled out at build time
>   if desired.
>   
>   Other than fixing some minor bugs, there are no user-visible changes from
>   this change

Can you also do "atomics" print?
Now debugs interleave w/ other outputs and line can split multiple
times.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r307319 - in head/sys/netinet: . tcp_stacks

[Slawa Olhovchenkov]

On Fri, Oct 14, 2016 at 02:57:43PM +, Jonathan T. Looney wrote:

> Author: jtl
> Date: Fri Oct 14 14:57:43 2016
> New Revision: 307319
> URL: https://svnweb.freebsd.org/changeset/base/307319
> 
> Log:
>   The code currently resets the keepalive timer each time a packet is
>   received on a TCP session that has entered the ESTABLISHED state. This
>   results in a lot of calls to reset the keepalive timer.
>   
>   This patch changes the behavior so we set the keepalive timer for the
>   keepalive idle time (TP_KEEPIDLE). When the keepalive timer fires, it will
>   first check to see if the session has been idle for TP_KEEPIDLE ticks. If
>   not, it will reschedule the keepalive timer for the time the session will
>   have been idle for TP_KEEPIDLE ticks.
>   
>   For a session with regular communication, the keepalive timer should fire
>   approximately once every TP_KEEPIDLE ticks. For sessions with irregular
>   communication, the keepalive timer might fire more often. But, the
>   disruption from a periodic keepalive timer should be less than the regular
>   cost of resetting the keepalive timer on every packet.
>   
>   (FWIW, this change saved approximately 1.73% of the busy CPU cycles on a
>   particular test system with a heavy TCP output load. Of course, the
>   actual impact is very specific to the particular hardware and workload.)
>   
>   Reviewed by:gallatin, rrs
>   MFC after:  2 weeks
>   Sponsored by:   Netflix
>   Differential Revision:  https://reviews.freebsd.org/D8243

Some issus exist?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r311952 - head/sys/ddb

[Slawa Olhovchenkov]

On Sun, Jan 15, 2017 at 10:46:35AM -0800, Adrian Chadd wrote:

> url? :)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184987
Assignee:   Adrian Chadd

> On 15 January 2017 at 06:45, Slawa Olhovchenkov <s...@zxy.spb.ru> wrote:
> > On Sun, Jan 15, 2017 at 01:07:58PM +0800, Julian Elischer wrote:
> >
> >>
> >> the old DEC machines had (from memory) ^O  which dropped all pending
> >> output.
> >> Not so useful when there is 2MB of network buffers queued up to you,
> >> but very useful on
> >> and asr-33 teletype.
> >
> > Now it useful too, on serial console.
> > ^O processing be present years ago in FreeBSD, but removed at time of
> > tty code rewrite. As I know patch for restore exist, nobody
> > review/commit.
> >
> >
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r311952 - head/sys/ddb

[Slawa Olhovchenkov]

On Sun, Jan 15, 2017 at 01:07:58PM +0800, Julian Elischer wrote:

> 
> the old DEC machines had (from memory) ^O  which dropped all pending 
> output.
> Not so useful when there is 2MB of network buffers queued up to you, 
> but very useful on
> and asr-33 teletype.

Now it useful too, on serial console.
^O processing be present years ago in FreeBSD, but removed at time of
tty code rewrite. As I know patch for restore exist, nobody
review/commit.

___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r310023 - in head/sys/cddl: compat/opensolaris/sys contrib/opensolaris/uts/common/fs/zfs

[Slawa Olhovchenkov]

On Wed, Dec 14, 2016 at 02:38:11PM +0200, Andriy Gapon wrote:

> Alexander,
> 
> I tried to see how the code looks after expanding illumos variables to FreeBSD
> variables before and after your change.
> 
> Before:
> n = PAGESIZE * ((int64_t)freemem - zfs_arc_free_target);
> ==>
> n = PAGESIZE * ((int64_t)vm_cnt.v_free_count - zfs_arc_free_target);
> 
> After:
> n = PAGESIZE * (freemem - lotsfree - needfree - desfree);
> ==>
> n = PAGESIZE * ((long)vm_cnt.v_free_count - zfs_arc_free_target -
> (long)vm_pageout_deficit - (long)vm_cnt.v_free_target);
> 
> Default value of zfs_arc_free_target is vm_pageout_wakeup_thresh and its 
> default
> value is (vm_cnt.v_free_min / 10) * 11.
> 
> vm_pageout_deficit is probably just a noise most of the time.

vm_pageout_deficit zeroed at read by vm_pageout_scan().

In illumos case target is "target_free" + "pageout_high_water" + "extra
pages here to make sure the scanner doesn't start up while we're
freeing memory."

As zero-order approximation we can let

target_free as v_free_target (desfree)
pageout_high_water as zfs_arc_free_target (lotsfree)
extra pages as vm_pageout_deficit (needfree)

In that case noise in vm_pageout_deficit is not problem.

> But v_free_target is a substantial value (even greater than the default
> zfs_arc_free_target).
> 
> It seems that now we subtract much more than we did before.

Code was totaly broken in FreeBSD case: needfree don't updated in process of
reclaim. Mostly reclaim stops only after ARC touch arc_min.

> So, this change does not merely reduce diff, it also changes ARC sizing 
> behavior.

And this is right way.

> I wonder how much testing have you done for this change and if you can qualify
> ARC size behavior in various scenarios.  I expect that with your change the 
> ARC
> would more easily give in to the memory pressure.  That may delight some, but 
> it
> could be an issue for others.  Especially if it forces ARC to its minimum size
> for no good reason.
> 
> P.S.
> My impression is that the page daemon in illumos has a different algorithm 
> from
> our page daemon, so some similarities could be misleading rather than helpful.
> 
> -- 
> Andriy Gapon
> ___
> svn-src-all@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r309703 - in head/sys: amd64/amd64 arm64/arm64 i386/i386 vm

[Slawa Olhovchenkov]

On Thu, Dec 08, 2016 at 04:29:29AM +, Alan Cox wrote:

> Author: alc
> Date: Thu Dec  8 04:29:29 2016
> New Revision: 309703
> URL: https://svnweb.freebsd.org/changeset/base/309703
> 
> Log:
>   Previously, vm_radix_remove() would panic if the radix trie didn't
>   contain a vm_page_t at the specified index.  However, with this
>   change, vm_radix_remove() no longer panics.  Instead, it returns NULL
>   if there is no vm_page_t at the specified index.  Otherwise, it
>   returns the vm_page_t.  The motivation for this change is that it
>   simplifies the use of radix tries in the amd64, arm64, and i386 pmap
>   implementations.  Instead of performing a lookup before every remove,
>   the pmap can simply perform the remove.

Is this performance improvement?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r305852 - in head/sys: dev/cxgbe dev/cxgbe/firmware modules/cxgbe modules/cxgbe/if_cc modules/cxgbe/if_ccv

[Slawa Olhovchenkov]

On Fri, Sep 16, 2016 at 12:08:37AM +, Navdeep Parhar wrote:

> Author: np
> Date: Fri Sep 16 00:08:37 2016
> New Revision: 305852
> URL: https://svnweb.freebsd.org/changeset/base/305852
> 
> Log:
>   cxgbe(4): Attach to cards with the Terminator 6 ASIC.  T6 cards will
>   come up as 't6nex' nexus devices with 'cc' ports hanging off them.
>   
>   The T6 firmware and configuration files will be added as soon as they
>   are released.  For now the driver will try to work with whatever
>   firmware and configuration is on the card's flash.
>   
>   Sponsored by:   Chelsio Communications

No MFC planed?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r307326 - head/sys/boot/efi/loader

[Slawa Olhovchenkov]

On Wed, Oct 19, 2016 at 04:33:39PM -0600, Warner Losh wrote:

> On Wed, Oct 19, 2016 at 11:34 AM, John Baldwin  wrote:
> > On Wednesday, October 19, 2016 02:01:18 AM Warner Losh wrote:
> >> One of my systems would export these as sysctls:
> >>
> >> smbios.bios.reldate="07/05/2013"
> >> smbios.bios.vendor="American Megatrends Inc."
> >> smbios.bios.version="3.00"
> >> smbios.chassis.maker="Supermicro"
> >> smbios.chassis.serial="0123456789"
> >> smbios.chassis.tag="To Be Filled By O.E.M."
> >> smbios.chassis.version="0123456789"
> >> smbios.memory.enabled="268435456"
> >> smbios.planar.location="To be filled by O.E.M."
> >> smbios.planar.maker="Supermicro"
> >> smbios.planar.product="X9SRH-7F/7TF"
> >> smbios.planar.serial="VM13CS028237"
> >> smbios.planar.tag="To be filled by O.E.M."
> >> smbios.planar.version="0123456789"
> >> smbios.socket.enabled="1"
> >> smbios.socket.populated="1"
> >> smbios.system.family="To be filled by O.E.M."
> >> smbios.system.maker="Supermicro"
> >> smbios.system.product="X9SRH-7F/7TF"
> >> smbios.system.serial="0123456789"
> >> smbios.system.sku="To be filled by O.E.M."
> >> smbios.system.uuid="----002590e4d0ec"
> >> smbios.system.version="0123456789"
> >> smbios.version="2.7"
> >>
> >> though some of them are silly due to the BIOS writer being silly...
> >
> > So are you planning to just duplicate the existing kenv vars as sysctl
> > nodes?  Can't you parse the output of kenv instead?
> 
> I often get sysctl -a from ailing systems. I never or rarely get kenv.
> This adds to the information available when I'm looking into problems
> since it gives me more data about the system where the problem occurs.

Look like we need show-tech in base system
:)
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r306680 - in head/sys: amd64/amd64 amd64/include i386/include x86/include x86/x86

[Slawa Olhovchenkov]

On Wed, Oct 12, 2016 at 06:30:09PM +0300, Andriy Gapon wrote:

> On 12/10/2016 16:45, Konstantin Belousov wrote:
> > On Wed, Oct 12, 2016 at 04:25:00PM +0300, Andriy Gapon wrote:
> >> On 04/10/2016 20:01, Konstantin Belousov wrote:
> >>> Author: kib
> >>> Date: Tue Oct  4 17:01:24 2016
> >>> New Revision: 306680
> >>> URL: https://svnweb.freebsd.org/changeset/base/306680
> >>>
> >>> Log:
> >>>   Re-apply r306516 (by cem):
> >>>   
> >>>   Reduce the cost of TLB invalidation on x86 by using per-CPU completion 
> >>> flags
> >>>   
> >>>   Reduce contention during TLB invalidation operations by using a per-CPU
> >>>   completion flag, rather than a single atomically-updated variable.
> >>
> >> Kostik,
> >>
> >> could this commit cause a problem reported in the below links?
> >> https://bz-attachments.freebsd.org/attachment.cgi?id=175614
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213371
> > 
> > If I am reading the report right, the problem appears on the
> > 11.0-RELEASE system. The patch you reference was only applied to HEAD a
> > week ago and was not merged even to stable/11.
> 
> Sorry for the noise, then.  Somehow I thought that this went into the release
> branch, but obviously there was too little time for that.
> 
> > The examination must start with backtracing the thread which owns the
> > smp_ipi_mtx (shown on the screenshot).
> 
> It looks like DDB is not in GENERIC in 11.0?

Yes, DDB is absent in GENERIC 11.0

> Not sure if the reporter would be able to configure a dump device and then 
> save
> the dump given that the panic happens in the installer.
> If anyone could provide them with instructions that would be great.
> 
> -- 
> Andriy Gapon
> ___
> svn-src-all@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r307082 - in head: . sys/amd64/conf sys/arm/conf sys/arm64/conf sys/conf sys/i386/conf sys/mips/conf sys/modules/cc sys/modules/khelp sys/netinet sys/netinet/tcp_stacks sys/pc98/conf s

[Slawa Olhovchenkov]

On Wed, Oct 12, 2016 at 02:16:42AM +, Jonathan T. Looney wrote:

> Author: jtl
> Date: Wed Oct 12 02:16:42 2016
> New Revision: 307082
> URL: https://svnweb.freebsd.org/changeset/base/307082
> 
> Log:
>   In the TCP stack, the hhook(9) framework provides hooks for kernel modules
>   to add actions that run when a TCP frame is sent or received on a TCP
>   session in the ESTABLISHED state. In the base tree, this functionality is
>   only used for the h_ertt module, which is used by the cc_cdg, cc_chd, cc_hd,
>   and cc_vegas congestion control modules.
>   
>   Presently, we incur overhead to check for hooks each time a TCP frame is
>   sent or received on an ESTABLISHED TCP session.

Do you perform estimate of performane impact of this overhead?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r306661 - in stable/11/sys/dev/cxgbe: . tom

[Slawa Olhovchenkov]

On Mon, Oct 10, 2016 at 12:21:14PM -0700, John Baldwin wrote:

> On Monday, October 10, 2016 09:43:57 PM Slawa Olhovchenkov wrote:
> > On Mon, Oct 10, 2016 at 11:39:24AM -0700, John Baldwin wrote:
> > 
> > > On Monday, October 10, 2016 09:28:21 PM Slawa Olhovchenkov wrote:
> > > > On Mon, Oct 10, 2016 at 10:46:27AM -0700, John Baldwin wrote:
> > > > 
> > > > > On Monday, October 10, 2016 02:09:01 PM Slawa Olhovchenkov wrote:
> > > > > > On Mon, Oct 03, 2016 at 11:15:44PM +, John Baldwin wrote:
> > > > > > 
> > > > > > > Author: jhb
> > > > > > > Date: Mon Oct  3 23:15:44 2016
> > > > > > > New Revision: 306661
> > > > > > > URL: https://svnweb.freebsd.org/changeset/base/306661
> > > > > > > 
> > > > > > > Log:
> > > > > > >   MFC 303405: Add support for zero-copy aio_write() on TOE 
> > > > > > > sockets.
> > > > > > >   
> > > > > > >   AIO write requests for a TOE socket on a Chelsio T4+ adapter 
> > > > > > > can now
> > > > > > >   DMA directly from the user-supplied buffer.  This is 
> > > > > > > implemented by
> > > > > > >   wiring the pages backing the user-supplied buffer and queueing 
> > > > > > > special
> > > > > > >   mbufs backed by raw VM pages to the socket buffer.  The TOE code
> > > > > > >   recognizes these special mbufs and builds a sglist from the VM 
> > > > > > > page
> > > > > > >   array associated with the mbuf when queueing a work request to 
> > > > > > > the TOE.
> > > > > > >   
> > > > > > >   Because these mbufs do not have an associated virtual address, 
> > > > > > > m_data
> > > > > > >   is not valid.  Thus, the AIO handler does not invoke sosend() 
> > > > > > > directly
> > > > > > >   for these mbufs but instead inlines portions of 
> > > > > > > sosend_generic() and
> > > > > > >   tcp_usr_send().
> > > > > > >   
> > > > > > >   An aiotx_buffer structure is used to describe the user buffer 
> > > > > > > (e.g.
> > > > > > >   it holds the array of VM pages and a reference to the AIO job). 
> > > > > > >  The
> > > > > > >   special mbufs reference this structure via m_ext.  Note that a 
> > > > > > > single
> > > > > > >   job might be split across multiple mbufs (e.g. if it is larger 
> > > > > > > than
> > > > > > >   the socket buffer size).  The 'ext_arg2' member of each mbuf 
> > > > > > > gives an
> > > > > > >   offset relative to the backing aiotx_buffer.  The AIO job 
> > > > > > > associated
> > > > > > >   with an aiotx_buffer structure is completed when the last 
> > > > > > > reference to
> > > > > > >   the structure is released.
> > > > > > >   
> > > > > > >   Zero-copy aio_write()'s for connections associated with a given
> > > > > > >   adapter can be enabled/disabled at runtime via the
> > > > > > >   'dev.t[45]nex.N.toe.tx_zcopy' sysctl.
> > > > > > >   
> > > > > > >   Sponsored by:   Chelsio Communications
> > > > > > 
> > > > > > Do you have any public available application patches for support 
> > > > > > this?
> > > > > > May be nginx?
> > > > > 
> > > > > Applications need to use aio_read(), ideally with at least 2 buffers 
> > > > > (so
> > > > > queue two reads, then when a read completes, consume the data and do 
> > > > > the
> > > > > next read).  I'm not sure nginx will find this but so useful as web 
> > > > > servers
> > > > > tend to send a lot more data than they receive.  The only software I 
> > > > > have
> > > > > patched explicitly for this is netperf.
> > > > 
> > > > Hm, this is like only aio_read() on sokets give performance boost, not
> > > > aio_write()?
> > > 
> > > Sorry, I was confused on the commit, this does affect aio_write() (earlier
> > > changes also permit zero-copy for receive via aio_read()).  However, as 
> > > you
> > > noted in the reply to Navdeep, it seems that nginx only supports using
> > > AIO on the backing files for static content it seems.  It would need 
> > > changes
> > > to support using aio_write on sockets (similar to using sendfile).
> > 
> > Thanks
> > You don't planed to do this?
> 
> After talking with Navdeep it looks like I will take a stab at adding support
> for this and seeing what effects it has.  For static content workloads using
> sendfile I'm not sure it will be a win, but it might let you avoid some of
> the CPU cycles for dynamically-generated content by avoiding copies for those.

As I remember you tests show performance boost over sendfile.
Also, sendfile over ZFS don't work good, as I remember (readahead
don't work, at least).
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r306661 - in stable/11/sys/dev/cxgbe: . tom

[Slawa Olhovchenkov]

On Mon, Oct 10, 2016 at 11:39:24AM -0700, John Baldwin wrote:

> On Monday, October 10, 2016 09:28:21 PM Slawa Olhovchenkov wrote:
> > On Mon, Oct 10, 2016 at 10:46:27AM -0700, John Baldwin wrote:
> > 
> > > On Monday, October 10, 2016 02:09:01 PM Slawa Olhovchenkov wrote:
> > > > On Mon, Oct 03, 2016 at 11:15:44PM +, John Baldwin wrote:
> > > > 
> > > > > Author: jhb
> > > > > Date: Mon Oct  3 23:15:44 2016
> > > > > New Revision: 306661
> > > > > URL: https://svnweb.freebsd.org/changeset/base/306661
> > > > > 
> > > > > Log:
> > > > >   MFC 303405: Add support for zero-copy aio_write() on TOE sockets.
> > > > >   
> > > > >   AIO write requests for a TOE socket on a Chelsio T4+ adapter can now
> > > > >   DMA directly from the user-supplied buffer.  This is implemented by
> > > > >   wiring the pages backing the user-supplied buffer and queueing 
> > > > > special
> > > > >   mbufs backed by raw VM pages to the socket buffer.  The TOE code
> > > > >   recognizes these special mbufs and builds a sglist from the VM page
> > > > >   array associated with the mbuf when queueing a work request to the 
> > > > > TOE.
> > > > >   
> > > > >   Because these mbufs do not have an associated virtual address, 
> > > > > m_data
> > > > >   is not valid.  Thus, the AIO handler does not invoke sosend() 
> > > > > directly
> > > > >   for these mbufs but instead inlines portions of sosend_generic() and
> > > > >   tcp_usr_send().
> > > > >   
> > > > >   An aiotx_buffer structure is used to describe the user buffer (e.g.
> > > > >   it holds the array of VM pages and a reference to the AIO job).  The
> > > > >   special mbufs reference this structure via m_ext.  Note that a 
> > > > > single
> > > > >   job might be split across multiple mbufs (e.g. if it is larger than
> > > > >   the socket buffer size).  The 'ext_arg2' member of each mbuf gives 
> > > > > an
> > > > >   offset relative to the backing aiotx_buffer.  The AIO job associated
> > > > >   with an aiotx_buffer structure is completed when the last reference 
> > > > > to
> > > > >   the structure is released.
> > > > >   
> > > > >   Zero-copy aio_write()'s for connections associated with a given
> > > > >   adapter can be enabled/disabled at runtime via the
> > > > >   'dev.t[45]nex.N.toe.tx_zcopy' sysctl.
> > > > >   
> > > > >   Sponsored by:   Chelsio Communications
> > > > 
> > > > Do you have any public available application patches for support this?
> > > > May be nginx?
> > > 
> > > Applications need to use aio_read(), ideally with at least 2 buffers (so
> > > queue two reads, then when a read completes, consume the data and do the
> > > next read).  I'm not sure nginx will find this but so useful as web 
> > > servers
> > > tend to send a lot more data than they receive.  The only software I have
> > > patched explicitly for this is netperf.
> > 
> > Hm, this is like only aio_read() on sokets give performance boost, not
> > aio_write()?
> 
> Sorry, I was confused on the commit, this does affect aio_write() (earlier
> changes also permit zero-copy for receive via aio_read()).  However, as you
> noted in the reply to Navdeep, it seems that nginx only supports using
> AIO on the backing files for static content it seems.  It would need changes
> to support using aio_write on sockets (similar to using sendfile).

Thanks
You don't planed to do this?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r306661 - in stable/11/sys/dev/cxgbe: . tom

[Slawa Olhovchenkov]

On Mon, Oct 10, 2016 at 10:46:27AM -0700, John Baldwin wrote:

> On Monday, October 10, 2016 02:09:01 PM Slawa Olhovchenkov wrote:
> > On Mon, Oct 03, 2016 at 11:15:44PM +, John Baldwin wrote:
> > 
> > > Author: jhb
> > > Date: Mon Oct  3 23:15:44 2016
> > > New Revision: 306661
> > > URL: https://svnweb.freebsd.org/changeset/base/306661
> > > 
> > > Log:
> > >   MFC 303405: Add support for zero-copy aio_write() on TOE sockets.
> > >   
> > >   AIO write requests for a TOE socket on a Chelsio T4+ adapter can now
> > >   DMA directly from the user-supplied buffer.  This is implemented by
> > >   wiring the pages backing the user-supplied buffer and queueing special
> > >   mbufs backed by raw VM pages to the socket buffer.  The TOE code
> > >   recognizes these special mbufs and builds a sglist from the VM page
> > >   array associated with the mbuf when queueing a work request to the TOE.
> > >   
> > >   Because these mbufs do not have an associated virtual address, m_data
> > >   is not valid.  Thus, the AIO handler does not invoke sosend() directly
> > >   for these mbufs but instead inlines portions of sosend_generic() and
> > >   tcp_usr_send().
> > >   
> > >   An aiotx_buffer structure is used to describe the user buffer (e.g.
> > >   it holds the array of VM pages and a reference to the AIO job).  The
> > >   special mbufs reference this structure via m_ext.  Note that a single
> > >   job might be split across multiple mbufs (e.g. if it is larger than
> > >   the socket buffer size).  The 'ext_arg2' member of each mbuf gives an
> > >   offset relative to the backing aiotx_buffer.  The AIO job associated
> > >   with an aiotx_buffer structure is completed when the last reference to
> > >   the structure is released.
> > >   
> > >   Zero-copy aio_write()'s for connections associated with a given
> > >   adapter can be enabled/disabled at runtime via the
> > >   'dev.t[45]nex.N.toe.tx_zcopy' sysctl.
> > >   
> > >   Sponsored by:   Chelsio Communications
> > 
> > Do you have any public available application patches for support this?
> > May be nginx?
> 
> Applications need to use aio_read(), ideally with at least 2 buffers (so
> queue two reads, then when a read completes, consume the data and do the
> next read).  I'm not sure nginx will find this but so useful as web servers
> tend to send a lot more data than they receive.  The only software I have
> patched explicitly for this is netperf.

Hm, this is like only aio_read() on sokets give performance boost, not
aio_write()?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r306661 - in stable/11/sys/dev/cxgbe: . tom

[Slawa Olhovchenkov]

On Mon, Oct 10, 2016 at 11:13:20AM -0700, Navdeep Parhar wrote:

> On 10/10/2016 04:09, Slawa Olhovchenkov wrote:
> > On Mon, Oct 03, 2016 at 11:15:44PM +, John Baldwin wrote:
> > 
> >> Author: jhb
> >> Date: Mon Oct  3 23:15:44 2016
> >> New Revision: 306661
> >> URL: https://svnweb.freebsd.org/changeset/base/306661
> >>
> >> Log:
> >>   MFC 303405: Add support for zero-copy aio_write() on TOE sockets.
> >>   
> >> ...
> > 
> > Do you have any public available application patches for support this?
> 
> netperf has support for AIO in its trunk/ branch and I assume it will be
> part of the next netperf release.
> 
> > May be nginx?
> > 
> 
> You don't need any patches if nginx supports AIO (aio_write(2) on the
> socket) already.  There's usually a knob in such applications that lets

No, nginx currently don't supports AIO on the socket.

> you select the method it uses to transmit data.  That's probably the
> best place to start looking.
> 
> Regards,
> Navdeep
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r306661 - in stable/11/sys/dev/cxgbe: . tom

[Slawa Olhovchenkov]

On Mon, Oct 03, 2016 at 11:15:44PM +, John Baldwin wrote:

> Author: jhb
> Date: Mon Oct  3 23:15:44 2016
> New Revision: 306661
> URL: https://svnweb.freebsd.org/changeset/base/306661
> 
> Log:
>   MFC 303405: Add support for zero-copy aio_write() on TOE sockets.
>   
>   AIO write requests for a TOE socket on a Chelsio T4+ adapter can now
>   DMA directly from the user-supplied buffer.  This is implemented by
>   wiring the pages backing the user-supplied buffer and queueing special
>   mbufs backed by raw VM pages to the socket buffer.  The TOE code
>   recognizes these special mbufs and builds a sglist from the VM page
>   array associated with the mbuf when queueing a work request to the TOE.
>   
>   Because these mbufs do not have an associated virtual address, m_data
>   is not valid.  Thus, the AIO handler does not invoke sosend() directly
>   for these mbufs but instead inlines portions of sosend_generic() and
>   tcp_usr_send().
>   
>   An aiotx_buffer structure is used to describe the user buffer (e.g.
>   it holds the array of VM pages and a reference to the AIO job).  The
>   special mbufs reference this structure via m_ext.  Note that a single
>   job might be split across multiple mbufs (e.g. if it is larger than
>   the socket buffer size).  The 'ext_arg2' member of each mbuf gives an
>   offset relative to the backing aiotx_buffer.  The AIO job associated
>   with an aiotx_buffer structure is completed when the last reference to
>   the structure is released.
>   
>   Zero-copy aio_write()'s for connections associated with a given
>   adapter can be enabled/disabled at runtime via the
>   'dev.t[45]nex.N.toe.tx_zcopy' sysctl.
>   
>   Sponsored by:   Chelsio Communications

Do you have any public available application patches for support this?
May be nginx?
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r306346 - head/sys/kern

[Slawa Olhovchenkov]

On Thu, Oct 06, 2016 at 02:08:46PM +1100, Bruce Evans wrote:

> On Wed, 5 Oct 2016, Slawa Olhovchenkov wrote:
> 
> > On Wed, Oct 05, 2016 at 11:19:10AM +1100, Bruce Evans wrote:
> >
> >> On Tue, 4 Oct 2016, Gleb Smirnoff wrote:
> >>
> >>> On Mon, Sep 26, 2016 at 03:30:30PM +, Eric van Gyzen wrote:
> >>> E> ...
> >>> E> Modified: head/sys/kern/kern_mutex.c
> >>> E> 
> >>> ==
> >>> E> --- head/sys/kern/kern_mutex.c Mon Sep 26 15:03:31 2016
> >>> (r306345)
> >>> E> +++ head/sys/kern/kern_mutex.c Mon Sep 26 15:30:30 2016
> >>> (r306346)
> >>> E> @@ -924,7 +924,7 @@ __mtx_assert(const volatile uintptr_t *c
> >>> E>  {
> >>> E>const struct mtx *m;
> >>> E>
> >>> E> -  if (panicstr != NULL || dumping)
> >>> E> +  if (panicstr != NULL || dumping || SCHEDULER_STOPPED())
> >>> E>return;
> >>>
> >>> I wonder if all this disjunct can be reduced just to SCHEDULER_STOPPED()?
> >>> Positive panicstr and dumping imply scheduler stopped.
> >>
> >> 'dumping' doesn't imply SCHEDULER_STOPPED().
> >>
> >> Checking 'dumping' here seems to be just an old bug.  It just breaks
> >> __mtx_assert(), while all other mutex operations work normally for dumping
> >> without panicing.
> >
> > [...]
> >
> > Is this related to halted (not reboted) 11.0 after ~^B and `panic`?
> 
> There might be related problems, but I don't see any here.
> 
> > What I see on serial console:
> > =
> > db> panic
> > panic: from debugger
> 
> I wouldn't trust panic from the debugger, but it is safer than dump
> from the debugger (both are ddb commands, but this is another bug).
> 
> > cpuid = 1
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at 0x8031fadb = 
> > db_trace_self_wrapper+0x2b/frame 0xfe1f9e198120
> > vpanic() at 0x804a0302 = vpanic+0x182/frame 0xfe1f9e1981a0
> > panic() at 0x804a0383 = panic+0x43/frame 0xfe1f9e198200
> > db_panic() at 0x8031d987 = db_panic+0x17/frame 0xfe1f9e198210
> > db_command() at 0x8031d019 = db_command+0x299/frame 
> > 0xfe1f9e1982e0
> > db_command_loop() at 0x8031cd74 = db_command_loop+0x64/frame 
> > 0xfe1f9e1982f0
> > db_trap() at 0x8031fc1b = db_trap+0xdb/frame 0xfe1f9e198380
> > kdb_trap() at 0x804dd8c3 = kdb_trap+0x193/frame 0xfe1f9e198410
> > trap() at 0x806e3065 = trap+0x255/frame 0xfe1f9e198620
> > calltrap() at 0x806cafd1 = calltrap+0x8/frame 0xfe1f9e198620
> > --- trap 0x3, rip = 0x804dd11e, rsp = 0xfe1f9e1986f0, rbp = 
> > 0xfe1f9e198710 ---
> > kdb_alt_break_internal() at 0x804dd11e = 
> > kdb_alt_break_internal+0x18e/frame 0xfe1f9e198710
> > kdb_alt_break() at 0x804dcf8b = kdb_alt_break+0xb/frame 
> > 0xfe1f9e198720
> > uart_intr_rxready() at 0x803e38a8 = uart_intr_rxready+0x98/frame 
> > 0xfe1f9e198750
> > uart_intr() at 0x803e4621 = uart_intr+0x121/frame 0xfe1f9e198790
> > intr_event_handle() at 0x8046c74b = intr_event_handle+0x9b/frame 
> > 0xfe1f9e1987e0
> > intr_execute_handlers() at 0x8076d2d8 = 
> > intr_execute_handlers+0x48/frame 0xfe1f9e198810
> > lapic_handle_intr() at 0x8077163f = lapic_handle_intr+0x3f/frame 
> > 0xfe1f9e198830
> > Xapic_isr1() at 0x806cb6b7 = Xapic_isr1+0xb7/frame 
> > 0xfe1f9e198830
> > --- interrupt, rip = 0x8032fedf, rsp = 0xfe1f9e198900, rbp = 
> > 0xfe1f9e198940 ---
> > acpi_cpu_idle() at 0x8032fedf = acpi_cpu_idle+0x2af/frame 
> > 0xfe1f9e198940
> > cpu_idle_acpi() at 0x8076ad1f = cpu_idle_acpi+0x3f/frame 
> > 0xfe1f9e198960
> > cpu_idle() at 0x8076adc5 = cpu_idle+0x95/frame 0xfe1f9e198980
> > sched_idletd() at 0x804cbbe5 = sched_idletd+0x495/frame 
> > 0xfe1f9e198a70
> > fork_exit() at 0x8046a211 = fork_exit+0x71/frame 0xfe1f9e198ab0
> > fork_trampoline() at 0x806cb50e = fork_trampoline+0xe/frame 
> > 0xfe1f9e198ab0
> > --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> 
> This looks like a normal kdb entry then a not so normal panic from ddb,
> but no problems.

Yes, I am just capture all output from console after command (`panic