Re: kern.sched.quantum: Creepy, sadistic scheduler

[Peter]

Eugene Grosbein wrote:


I see no reasons to use SHED_ULE for such single core systems and use SCHED_BSD.


Nitpicking: it is not a single core system, it's a dual that for now is 
equipped with only one chip, the other is in the shelf.


But seriously, I am currently working myself through the design papers
for the SCHED_ULE and the SMP stuff, and I tend to be with You and 
George, in that I do not really need these features.


Nevertheless, I think the system should have proper behaviour *as 
default*, or otherwise there should be a hint in the docs what to do about.
Thats the reason why I raise this issue - if the matter can be fixed, 
thats great, but if we come to the conclusion that 
small/single-core/CPU-bound/whatever systems are better off with 
SCHED_4BSD, then thats perfectly fine as well. Or maybe, that those 
systems should disable preemption? I currently don't know, but i hope we 
can figure this out, as the problem is clearly visible.


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

Re: Problems with ifconfig when starting all jails after 10.3 -> 10.4 upgrade

[Marc Branchaud]

On 2018-04-05 10:28 AM, Marc Branchaud wrote:

Hi all,

I just upgraded from 10.3 to 10.4, and "/etc/rc.d/jail start" is having 
problems starting all of my jails:


# /etc/rc.d/jail start
Starting jails:xipbuild_3_3: created
ifconfig:: bad value
jail: xipbuild_3_3_8: /sbin/ifconfig lo1 inet 10.1.1.38/32 alias: failed
xipbuild_3_4: created
ifconfig:: bad value
jail: xipbuild_4_0: /sbin/ifconfig lo1 inet 10.1.1.5/32 alias: failed
xipbuild: created
xipbuild_4_9: created
ifconfig:: bad value
jail: xipbuild9: /sbin/ifconfig lo1 inet 10.1.1.209/32 alias: failed
.


More info: Things work fine with jail_parallel_start="YES".

In 10.4, /etc/rc.d/jail now adds "-p1" to the jail command's arguments 
when starting all jails with jail_parallel_start="NO".  It's definitely 
this parameter that's causing my problems -- changing /etc/rc.d/jail to 
not add the parameter fixes the problem.


M.


This worked fine in 10.3.  I can individually start each jail, e.g. 
"/etc/rc.d/jail start xipbuild9".


All the jails configure the same set of parameters.  Here's my jail.conf:

--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---
xipbuild_3_3 {
   path="/usr/build-jails/jails/3.3";
   host.hostname="xipbuild_3_3";
   ip4.addr="10.1.1.3/32";

   allow.chflags;
   allow.mount;
   mount.devfs;

   persist;

   mount="/usr/home  /usr/build-jails/jails/3.3/usr/home nullfs rw 0 0";
   interface="lo1";
}
xipbuild_3_3_8 {
   path="/usr/build-jails/jails/3.3.8";
   host.hostname="xipbuild_3_3_8";
   ip4.addr="10.1.1.38/32";

   allow.chflags;
   allow.mount;
   mount.devfs;

   persist;

   mount="/usr/home  /usr/build-jails/jails/3.3.8/usr/home nullfs rw 0 0";
   interface="lo1";
}
xipbuild_3_4 {
   path="/usr/build-jails/jails/3.4";
   host.hostname="xipbuild_3_4";
   ip4.addr="10.1.1.4/32";

   allow.chflags;
   allow.mount;
   mount.devfs;

   persist;

   mount="/usr/home  /usr/build-jails/jails/3.4/usr/home nullfs rw 0 0";
   interface="lo1";
}
xipbuild_4_0 {
   path="/usr/build-jails/jails/4.0";
   host.hostname="xipbuild_4_0";
   ip4.addr="10.1.1.5/32";

   allow.chflags;
   allow.mount;
   mount.devfs;

   persist;

   mount="/usr/home  /usr/build-jails/jails/4.0/usr/home nullfs rw 0 0";
   interface="lo1";
}
xipbuild {
   path="/usr/build-jails/jails/latest";
   host.hostname="xipbuild";
   ip4.addr="10.1.1.200/32";

   allow.chflags;
   allow.mount;
   mount.devfs;

   persist;

   mount="/usr/home  /usr/build-jails/jails/latest/usr/home nullfs rw 0 0";
   interface="lo1";
}
xipbuild_4_9 {
   path="/usr/build-jails/jails/4.9";
   host.hostname="xipbuild_4_9";
   ip4.addr="10.1.1.90/32";

   allow.chflags;
   allow.mount;
   mount.devfs;

   persist;

   mount="/usr/home  /usr/build-jails/jails/4.9/usr/home nullfs rw 0 0";
   interface="lo1";
}
xipbuild9 {
   path="/usr/build-jails/jails/latest9";
   host.hostname="xipbuild9";
   ip4.addr="10.1.1.209/32";

   allow.chflags;
   allow.mount;
   mount.devfs;

   persist;

   mount="/usr/home  /usr/build-jails/jails/latest9/usr/home nullfs rw 0 
0";

   interface="lo1";
}
--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---

I use ipnat to give the jails network access.  Here's ipnat.rules:

--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---
map em0 10.1.1.0/24 -> 0/32 proxy port ftp ftp/tcp
map em0 10.1.1.0/24 -> 0/32
--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---

And here's my rc.conf:

--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---
# Generated by Ansible

# hostname must be FQDN
hostname="devastator.xiplink.com"

zfs_enable="False"

# FIXME: previously auto-created?
ifconfig_lo1="create"


ifconfig_em0="DHCP SYNCDHCP"

network_interfaces="em0"
gateway_enable="YES"

# Prevent rpc
rpcbind_enable="NO"

# Prevent sendmail to try to connect to localhost
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

# Bring up sshd, it takes some time and uses some entropy on first startup
sshd_enable="YES"

netwait_enable="YES"
netwait_ip="10.10.0.35"
netwait_if="em0"

jenkins_swarm_enable="YES"
jenkins_swarm_opts="-executors 8"

# --- Build jails ---
build_jails_enable="YES"
jail_enable="YES"

# Set rules in /etc/ipnat.rules
ipnat_enable="YES"

# Set interface name for ipnat
network_interfaces="${network_interfaces} lo1"

# Each jail needs to specify its IP address and mask bits in ipv4_addrs_lo1
ipv4_addrs_lo1="10.1.1.1/32"

jail_chflags_allow="yes"

varmfs="NO"
--- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< --- 8< ---

Any insight would be deeply appreciated!

     M.

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

Re: [Bug 227323] [patch] [spi] sys/modules/spi/mx25l cannot be built outside of kernel build environment

[Ian Lepore]

On Fri, 2018-04-06 at 13:09 +, bugzilla-nore...@freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227323
> 
> Bug ID: 227323
>    Summary: [patch] [spi] sys/modules/spi/mx25l cannot be
> built
> outside of kernel build environment
>    Product: Base System
>    Version: 11.1-STABLE
>   Hardware: Any
> OS: Any
> Status: New
>   Keywords: easy, patch-ready
>   Severity: Affects Some People
>   Priority: ---
>  Component: kern
>   Assignee: l...@freebsd.org
>   Reporter: eu...@freebsd.org
> CC: ead...@freebsd.org, i...@freebsd.org,
> sta...@freebsd.org
> 
> Created attachment 192286
>   --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192286
> on=edit
> The fix
> 
> # cd /usr/src/sys/modules/spi/mx25l && make
> cc -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
> -nostdinc  
> -I. -I/home/src/sys -fno-common  -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer   -MD  -MF.depend.mx25l.o -MTmx25l.o
> -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float 
> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-
> protector -Wall
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-
> prototypes
> -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
> -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-
> tautological-compare
> -Wno-error-empty-body -Wno-error-parentheses-equality
> -Wno-error-unused-function -Wno-error-pointer-sign
> -Wno-error-shift-negative-value -Wno-error-address-of-packed-
> member  -mno-aes
> -mno-avx  -std=iso9899:1999 -c /home/src/sys/dev/flash/mx25l.c -o
> mx25l.o
> /home/src/sys/dev/flash/mx25l.c:30:10: fatal error: 'opt_platform.h'
> file not
> found
> #include "opt_platform.h"
>  ^~~~
> 1 error generated.
> *** Error code 1
> 

Does anybody know why mailing lists have recently started being spammed
with bug reports?  Using the list to point out a bug that's been
languishing without attention for a while might be appropriate, but
spamming the list with every action on every bug, IMO, is not.

-- Ian

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

[Bug 227322] [patch] [iicbus] sys/modules/i2c/iicbus cannot be built outside of kernel build environment

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227322

Ian Lepore  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|New |Closed

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 227323] [patch] [spi] sys/modules/spi/mx25l cannot be built outside of kernel build environment

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227323

Ian Lepore  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|New |Closed

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 227322] [patch] [iicbus] sys/modules/i2c/iicbus cannot be built outside of kernel build environment

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227322

--- Comment #1 from commit-h...@freebsd.org ---
A commit references this bug:

Author: ian
Date: Fri Apr  6 16:48:08 UTC 2018
New revision: 332113
URL: https://svnweb.freebsd.org/changeset/base/332113

Log:
  MFC r331868:

  Add opt_platform.h for several modules that have #ifdef FDT in the source.

  Submitted by: Andre Albsmeier 

  PR:   227322 227323

Changes:
  stable/11/sys/modules/i2c/iicbus/Makefile
  stable/11/sys/modules/i2c/isl/Makefile
  stable/11/sys/modules/spi/at45d/Makefile
  stable/11/sys/modules/spi/mx25l/Makefile
  stable/11/sys/modules/spi/spibus/Makefile

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 227323] [patch] [spi] sys/modules/spi/mx25l cannot be built outside of kernel build environment

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227323

--- Comment #1 from commit-h...@freebsd.org ---
A commit references this bug:

Author: ian
Date: Fri Apr  6 16:48:08 UTC 2018
New revision: 332113
URL: https://svnweb.freebsd.org/changeset/base/332113

Log:
  MFC r331868:

  Add opt_platform.h for several modules that have #ifdef FDT in the source.

  Submitted by: Andre Albsmeier 

  PR:   227322 227323

Changes:
  stable/11/sys/modules/i2c/iicbus/Makefile
  stable/11/sys/modules/i2c/isl/Makefile
  stable/11/sys/modules/spi/at45d/Makefile
  stable/11/sys/modules/spi/mx25l/Makefile
  stable/11/sys/modules/spi/spibus/Makefile

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

libmap non-absolute paths broken in 11.1-STABLE

[Eugene Grosbein]

Hi!

I've just updated my desktop from early 11.1-STABLE to recent one 11.1-STABLE
and found that non-absolute paths do not work anymore, like this:

libevent-2.0.so.5 compat/pkg/libevent-2.0.so.5.1.10

With luck, this still works:

libevent-2.0.so.5 /usr/local/lib/compat/pkg/libevent-2.0.so.5.1.10

Is this known problem?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: TRIM, iSCSI and %busy waves

[Warner Losh]

On Fri, Apr 6, 2018 at 2:56 AM, Borja Marcos  wrote:

>
>
> On 6 Apr 2018, at 10:41, Steven Hartland  wrote:
>
> That is very hw and use case dependent.
>
> The reason we originally sponsored the project to add TRIM to ZFS was that
> in our case without TRIM the performance got so bad that we had to secure
> erase disks every couple of weeks as they simply became so slow they where
> unusable.
>
> Now admittedly that was a fair few years ago and hw has moved on since
> then, but the point remains that it’s not totally true that just not
> TRIMing is an option.
>
>
> As far as I know, letting the device know that you have released a block
> should be a Good Thing.
> So I prefer to TRIM. I have also seen cases where not doing TRIMs resulted
> in a terrible performance
> although modern SSDs should have better algorithms to deal with it.
>
> But I have also seen bad cases of TRIM requests piling up and clogging the
> queues for long periods
> of time. Admittedly it was a purely synthetic situation (running bonnie++)
> but, again, performing
> operations like destroying a huge snapshot or dataset could trigger a
> similar condition.  It was
> especially nasty when I tried NVMEs. I mentioned this here:
>
> https://lists.freebsd.org/pipermail/freebsd-fs/2016-May/023134.html
>
>
> That’s why I think there is a mid point between the radical approach of
> not doing TRIMs at all
> and clogging the queues with too many of them.
>

nvd is especially troublesome. It doesn't do any trim shaping *AT*ALL* and
we machine gun a huge number of TRIM requests when we delete large files.
TRIM is normally not a fast path operation inside the drives, so sending
lots of TRIMs down will often starve read/write resources for a variety of
reasons (it often forces single threading limiting the parallelism in the
drive, it often kicks off GC which causes lots of block erases which are
slow and block reads/writes to other pages/blocks on the die (some or all
mitigated by planes, but still), etc.


> If the TRIM queue gets very large and the “mandatory” operations (read,
> writes, etc) begin to
> get large delays I think it’s safe to assume that *there is* a problem and
> discarding at least part
> of those TRIMs could help to solve it.
>

That's often a property of the devices, however. And how quickly we shove
TRIMs down its throat. I've seen situations where we play out the TRIMs
slowly enough that we can see huge latencies in TRIMs (seconds to minutes),
but see little to no effect effect on read latency, even in the P99 number
since that's often where effects in TRIMs show up and are easiest to
measure.

Warner


> A “TRIM when you can” should still be better than a “Don’t TRIM at all”.
>
> Cheers,
>
>
>
>
>
> Borja.
>
> P.S: Attaching the graphs that were lost.
>
>
>
>
>
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: TRIM, iSCSI and %busy waves

[Warner Losh]

On Fri, Apr 6, 2018 at 1:58 AM, Borja Marcos  wrote:

>
> > On 5 Apr 2018, at 17:00, Warner Losh  wrote:
> >
> > I'm working on trim shaping in -current right now. It's focused on NVMe,
> > but since I'm doing the bulk of it in cam_iosched.c, it will eventually
> be
> > available for ada and da. The notion is to measure how long the TRIMs
> take,
> > and only send them at 80% of that rate when there's other traffic in the
> > queue (so if trims are taking 100ms, send them no faster than 8/s). While
> > this will allow for better read/write traffic, it does slow the TRIMs
> down
> > which slows down whatever they may be blocking in the upper layers. Can't
> > speak to ZFS much, but for UFS that's freeing of blocks so things like
> new
> > block allocation may be delayed if we're almost out of disk (which we
> have
> > no signal for, so there's no way for the lower layers to prioritize trims
> > or not).
>
> Have you considered "hard" shaping including discarding TRIMs when needed?
> Remember that a TRIM is not a write, which is subject to a contract with
> the application,
> but a better-if-you-do-it operation.
>

Well, yes and no. TRIM is there to improve performance, in the long term,
of the drives because they'd otherwise get too fragmented and/or have an
unacceptably high write amplification. It's more than just a hint, but
maybe, in some cases, less than a write. Better if you do it does give some
leeway, how much depends on the application. If we were to implement a hard
limit on the latency of TRIMs, it would have to be user configurable.
There's also the strategy of returning some TRIMs right away, while letting
only a percentage through to the device.

If I go through with what you're calling hard shaping, I'd also look for
ways to allow the upper layers to tell me to hurry up. We have it in the
buffer daemon between all the users of bufs when there's a buf shortage,
but no similar signal from UFS down to the device to tell it that the
results are needed NOW vs needed eventually. And the urgency of the need
varies somewhat over time. you could easily send down a boatload of TRIMs
with no urgent need for blocks, time passes, and then you have an urgent
need for blocks. So you can't add something to the bio going down that it's
needed or not since you might not have another TRIM to send down. A new BIO
type and/or a tweak to BIO_FLUSH might suffice and be well defined for
drivers that don't do weird things. The notion of the upper layers being
able to cancel a TRIM that's been queued up was also floated since TRIM +
WRITE in quick succession often gives no different performance than just
the bare WRITE. And I have no clue what ZFS does wrt TRIMs.

So I've considered it, yes. But there's more tricky corners here to
consider if it were to be implemented due to (a) the diversity of quality
in the market place and (b) the diversity of workloads FreeBSD is used for.


> Otherwise, as you say, you might be blocking other operations in the upper
> layers.
> I am assuming here that with many devices doing TRIMs is better than not
> doing them.
> And in case of queue congestion doing *some* TRIMs should be better than
> doing
> no TRIMs at all.
>
> Yep, not the first time I propose something of the sort, but my queue of
> suggestions
> to eventually discard TRIMs doesn’s implement the same method ;)
>

I'm looking at all options, to be honest. I'm not sure what will work the
best in the long term.

I've observed that, at least with UFS, it's quite easy to survive for hours
without finishing the trim with millions of TRIMs in the queue. All it
affects are monitoring programs that freak out when you have this many
items in the queue for so long (thinking something must be wrong). Of
coarse, we control the monitoring programs, so that's easy to fix. (I
discovered this when I was doing 1 IOP for TRIMs when running early, buggy
versions of this, btw). The backup causes UFS to be waiting on the blocks,
if there is a block shortage. Since most of the time there's not, this
didn't cause problems when I tweaked a parameter and drained the TRIMs 8
hours after tons of files were deleted

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

[Bug 227323] [patch] [spi] sys/modules/spi/mx25l cannot be built outside of kernel build environment

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227323

Bug ID: 227323
   Summary: [patch] [spi] sys/modules/spi/mx25l cannot be built
outside of kernel build environment
   Product: Base System
   Version: 11.1-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: easy, patch-ready
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: l...@freebsd.org
  Reporter: eu...@freebsd.org
CC: ead...@freebsd.org, i...@freebsd.org,
sta...@freebsd.org

Created attachment 192286
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192286=edit
The fix

# cd /usr/src/sys/modules/spi/mx25l && make
cc -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc  
-I. -I/home/src/sys -fno-common  -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer   -MD  -MF.depend.mx25l.o -MTmx25l.o
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
-D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-parentheses-equality
-Wno-error-unused-function -Wno-error-pointer-sign
-Wno-error-shift-negative-value -Wno-error-address-of-packed-member  -mno-aes
-mno-avx  -std=iso9899:1999 -c /home/src/sys/dev/flash/mx25l.c -o mx25l.o
/home/src/sys/dev/flash/mx25l.c:30:10: fatal error: 'opt_platform.h' file not
found
#include "opt_platform.h"
 ^~~~
1 error generated.
*** Error code 1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 227322] [patch] [iicbus] sys/modules/i2c/iicbus cannot be built outside of kernel build environment

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227322

Bug ID: 227322
   Summary: [patch] [iicbus] sys/modules/i2c/iicbus cannot be
built outside of kernel build environment
   Product: Base System
   Version: 11.1-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: easy, patch-ready
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: i...@freebsd.org
  Reporter: eu...@freebsd.org
CC: sta...@freebsd.org

Created attachment 192285
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192285=edit
The fix

# cd /usr/src/sys/modules/i2c/iicbus && make
cc -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc  
-I. -I/home/src/sys -fno-common  -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer   -MD  -MF.depend.iic_recover_bus.o
-MTiic_recover_bus.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
-msoft-float  -fno-asynchronous-unwind-tables -ffreestanding -fwrapv
-fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
-fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-parentheses-equality
-Wno-error-unused-function -Wno-error-pointer-sign
-Wno-error-shift-negative-value -Wno-error-address-of-packed-member  -mno-aes
-mno-avx  -std=iso9899:1999 -c /home/src/sys/dev/iicbus/iic_recover_bus.c -o
iic_recover_bus.o
/home/src/sys/dev/iicbus/iic_recover_bus.c:49:10: fatal error: 'opt_platform.h'
file not found
#include "opt_platform.h"
 ^~~~
1 error generated.
*** Error code 1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: TRIM, iSCSI and %busy waves

[Borja Marcos]

> On 6 Apr 2018, at 10:56, Borja Marcos  wrote:
> 
> P.S: Attaching the graphs that were lost.

And, silly me, repeating the same mistakes over and over.

http://frobula.crabdance.com:8001/publicfiles/OneBonnie.png
http://frobula.crabdance.com:8001/publicfiles/TwoBonniesTimes.png
http://frobula.crabdance.com:8001/publicfiles/TwoBonniesTput.png

Sorry!




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

Re: TRIM, iSCSI and %busy waves

[Borja Marcos]

> On 6 Apr 2018, at 10:41, Steven Hartland  wrote:
> 
> That is very hw and use case dependent.
> 
> The reason we originally sponsored the project to add TRIM to ZFS was that in 
> our case without TRIM the performance got so bad that we had to secure erase 
> disks every couple of weeks as they simply became so slow they where unusable.
> 
> Now admittedly that was a fair few years ago and hw has moved on since then, 
> but the point remains that it’s not totally true that just not TRIMing is an 
> option.

As far as I know, letting the device know that you have released a block should 
be a Good Thing. 
So I prefer to TRIM. I have also seen cases where not doing TRIMs resulted in a 
terrible performance
although modern SSDs should have better algorithms to deal with it. 

But I have also seen bad cases of TRIM requests piling up and clogging the 
queues for long periods
of time. Admittedly it was a purely synthetic situation (running bonnie++) but, 
again, performing
operations like destroying a huge snapshot or dataset could trigger a similar 
condition.  It was
especially nasty when I tried NVMEs. I mentioned this here:

https://lists.freebsd.org/pipermail/freebsd-fs/2016-May/023134.html


That’s why I think there is a mid point between the radical approach of not 
doing TRIMs at all
and clogging the queues with too many of them. 

If the TRIM queue gets very large and the “mandatory” operations (read, writes, 
etc) begin to
get large delays I think it’s safe to assume that *there is* a problem and 
discarding at least part
of those TRIMs could help to solve it. 

A “TRIM when you can” should still be better than a “Don’t TRIM at all”. 

Cheers,





Borja.

P.S: Attaching the graphs that were lost.








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

Re: TRIM, iSCSI and %busy waves

[Steven Hartland]

That is very hw and use case dependent.

The reason we originally sponsored the project to add TRIM to ZFS was that
in our case without TRIM the performance got so bad that we had to secure
erase disks every couple of weeks as they simply became so slow they where
unusable.

Now admittedly that was a fair few years ago and hw has moved on since
then, but the point remains that it’s not totally true that just not
TRIMing is an option.

On Fri, 6 Apr 2018 at 09:10, Borja Marcos  wrote:

>
> > On 5 Apr 2018, at 17:00, Warner Losh  wrote:
> >
> > I'm working on trim shaping in -current right now. It's focused on NVMe,
> > but since I'm doing the bulk of it in cam_iosched.c, it will eventually
> be
> > available for ada and da. The notion is to measure how long the TRIMs
> take,
> > and only send them at 80% of that rate when there's other traffic in the
> > queue (so if trims are taking 100ms, send them no faster than 8/s). While
> > this will allow for better read/write traffic, it does slow the TRIMs
> down
> > which slows down whatever they may be blocking in the upper layers. Can't
> > speak to ZFS much, but for UFS that's freeing of blocks so things like
> new
> > block allocation may be delayed if we're almost out of disk (which we
> have
> > no signal for, so there's no way for the lower layers to prioritize trims
> > or not).
>
> Have you considered "hard" shaping including discarding TRIMs when needed?
> Remember that a TRIM is not a write, which is subject to a contract with
> the application,
> but a better-if-you-do-it operation.
>
> Otherwise, as you say, you might be blocking other operations in the upper
> layers.
> I am assuming here that with many devices doing TRIMs is better than not
> doing them.
> And in case of queue congestion doing *some* TRIMs should be better than
> doing
> no TRIMs at all.
>
> Yep, not the first time I propose something of the sort, but my queue of
> suggestions
> to eventually discard TRIMs doesn’s implement the same method ;)
>
>
> Borja.
>
>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re:Response

[verogarcia]

Hello,

Please, Let me know if you received my message, I have sent more 
than 3 messages to you in the last 3 months without response,get 
back to me
Yours,
Veronica Garcia
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: TRIM, iSCSI and %busy waves

[Borja Marcos]

> On 5 Apr 2018, at 17:00, Warner Losh  wrote:
> 
> I'm working on trim shaping in -current right now. It's focused on NVMe,
> but since I'm doing the bulk of it in cam_iosched.c, it will eventually be
> available for ada and da. The notion is to measure how long the TRIMs take,
> and only send them at 80% of that rate when there's other traffic in the
> queue (so if trims are taking 100ms, send them no faster than 8/s). While
> this will allow for better read/write traffic, it does slow the TRIMs down
> which slows down whatever they may be blocking in the upper layers. Can't
> speak to ZFS much, but for UFS that's freeing of blocks so things like new
> block allocation may be delayed if we're almost out of disk (which we have
> no signal for, so there's no way for the lower layers to prioritize trims
> or not).

Have you considered "hard" shaping including discarding TRIMs when needed?
Remember that a TRIM is not a write, which is subject to a contract with the 
application,
but a better-if-you-do-it operation. 

Otherwise, as you say, you might be blocking other operations in the upper 
layers.
I am assuming here that with many devices doing TRIMs is better than not doing 
them.
And in case of queue congestion doing *some* TRIMs should be better than doing
no TRIMs at all.

Yep, not the first time I propose something of the sort, but my queue of 
suggestions 
to eventually discard TRIMs doesn’s implement the same method ;)


Borja.


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