Re: Call for Testing: UEFI Changes

2018-04-01 Thread Kyle Evans 
On Sun, Apr 1, 2018 at 7:38 AM, Tomoaki AOKI  wrote:
> Confirmed both loader (with boot1) part and efirt.ko part.
> Working OK on my ThinkPad420 (with nvidia GPU) at r331864.
>
> No benefit (VGA resolution) but no new harm (no panic nor silent
> reboot).
>
>  *Maybe gracefully falling back to mode 0.
>

Did you pick up the change on head that calls maybe-efi-resizecons?

On my X220, this bumps my resolution up to 1024x768.

> As I'm on x11/nvidia-driver, completely no test is done with
> drm-next.

This is ok. =)

> One more to mention.
> I've cherry-picked r330868, r331241 and r331361 on stable/11 after
> r331114, amd64 and works OK as on head.
> Additional cherry-picking of r331365 is OK, too.
>
> Without r330868, my ThinkPad silently reboots within about 10-60
> minutes range, maybe by actual access to UEFI RS.
> With r331241 without r331361 causes instant panic on loading efirt.ko.
> So all 3 (4) revs should be MFC'ed together.

Good to hear! We've marked all four of these to be MFC'd in one batch
anyways, just to make sure we don't horribly break things. We seem to
be in a pretty stable state at the moment on head from what I'm
hearing.

> Sorry for delay.

No worries. =)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

2018-04-01 Thread David NewHamlet 
Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso


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

On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI 
wrote:

> Confirmed both loader (with boot1) part and efirt.ko part.
> Working OK on my ThinkPad420 (with nvidia GPU) at r331864.
>
> No benefit (VGA resolution) but no new harm (no panic nor silent
> reboot).
>
>  *Maybe gracefully falling back to mode 0.
>
> As I'm on x11/nvidia-driver, completely no test is done with
> drm-next.
>
> One more to mention.
> I've cherry-picked r330868, r331241 and r331361 on stable/11 after
> r331114, amd64 and works OK as on head.
> Additional cherry-picking of r331365 is OK, too.
>
> Without r330868, my ThinkPad silently reboots within about 10-60
> minutes range, maybe by actual access to UEFI RS.
> With r331241 without r331361 causes instant panic on loading efirt.ko.
> So all 3 (4) revs should be MFC'ed together.
>
> Sorry for delay.
>
>
> On Thu, 22 Mar 2018 10:34:33 -0500
> Kyle Evans  wrote:
>
> > On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans  wrote:
> > > On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei 
> wrote:
> > >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote:
> > >>> Hi.
> > >>> For problem 2, try reverting r331241 alone.
> > >>> This worked for my ThinkPad T420.
> > >>
> > >>
> > >> I also hit this after updating to latest and was about to post when I
> > >> saw this thread -
> > >>
> > >> I build efirt into the kernel and it's now doing a panic on boot. It
> > >> appears to be due to this recent addition in dev/efidev/efirt.c by
> r331241:
> > >>
> > >>> if (!efi_is_in_map(map, efihdr->memory_size /
> efihdr->descriptor_size,
> > >>> efihdr->descriptor_size, 
> > >>> (vm_offset_t)efi_runtime->rt_gettime))
> {
> > >>
> > >> The faulting address is for "efi_runtime->rt_gettime" (and is still a
> > >> phys addr here).
> > >>
> > >
> > > The following patch [1] (I can't guarantee how long he'll keep it
> > > available there) should fix this class of problems.
> > >
> > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the-
> EFI-environment-before-check-the-GetT.patch
> >
> > Now committed as of r331361.
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
> >
>
>
> --
> Tomoaki AOKI
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Extremely low disk throughput under high compute load

2018-04-01 Thread Stefan Esser 
Am 01.04.18 um 18:33 schrieb Warner Losh:
> 
> 
> On Sun, Apr 1, 2018 at 9:18 AM, Stefan Esser  > wrote:
> 
> My i7-2600K based system with 24 GB RAM was in the midst of a buildworld 
> -j8
> (starting from a clean state) which caused a load average of 12 for more 
> than
> 1 hour, when I decided to move a directory structure holding some 10 GB 
> to its
> own ZFS file system. File sizes varied, but were mostly in the range 0f 
> 500KB.
> 
> I had just thrown away /usr/obj, but /usr/src was cached in ARC and thus 
> there
> was nearly no disk activity caused by the buildworld.
> 
> The copying proceeded at a rate of at most 10 MB/s, but most of the time 
> less
> than 100 KB/s were transferred. The "cp" process had a PRIO of 20 and 
> thus a
> much better priority than the compute bound compiler processes, but it got
> just 0.2% to 0.5% of 1 CPU core. Apparently, the copy process was 
> scheduled
> at such a low rate, that it only managed to issue a few controller writes 
> per
> second.
> 
> The system is healthy and does not show any problems or anomalies under
> normal use (e.g., file copies are fast, without the high compute load).
> 
> This was with SCHED_ULE on a -CURRENT without WITNESS or malloc debugging.
> 
> Is this a regression in -CURRENT?
> 
> Does 'sync' push a lot of I/O to the disk?

Each sync takes 0.7 to 1.5 seconds to complete, but since reading is so
slow, not much is written.

Normal gstat output for the 3 drives the RAIDZ1 consists of:

dT: 1.002s  w: 1.000s
 L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/w   %busy Name
0  2  2 84   39.1  0  00.07.8  ada0
0  4  4 92   66.6  0  00.0   26.6  ada1
0  6  6259   66.9  0  00.0   36.2  ada3
dT: 1.058s  w: 1.000s
 L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/w   %busy Name
0  1  1 60   70.6  0  00.06.7  ada0
0  3  3 68   71.3  0  00.0   20.2  ada1
0  6  6242   65.5  0  00.0   28.8  ada3
dT: 1.002s  w: 1.000s
 L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/w   %busy Name
0  5  5192   44.8  0  00.0   22.4  ada0
0  6  6160   61.9  0  00.0   26.5  ada1
0  6  6172   43.7  0  00.0   26.2  ada3

This includes the copy process and the reads caused by "make -j 8 world"
(but I assume that all the source files are already cached in ARC).

During sync:

dT: 1.002s  w: 1.000s
 L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/w   %busy Name
1101  9132   14.6 90   17605.6   59.7  ada0
2110 16267   15.0 92   17566.0   50.7  ada1
2 82 13291   17.8 67   16537.4   34.3  ada3

ZFS is configured to flush dirty buffers after 5 seconds, so there are
not many dirty buffers in RAM at any time, anyway.

> Is the effective throughput of CP tiny or large? It's tiny, if I read right,
> and the I/O is slow (as opposed to it all buffering in memory and being slow
> to drain own), right?

Yes, reading is very slow, with less than 10 read operations scheduled
per second.

Top output taken at the same time as above gstat samples:

last pid: 24306;  load averages: 12.07, 11.51,  8.13

  up 2+05:41:57  00:10:22
132 processes: 10 running, 122 sleeping
CPU: 98.2% user,  0.0% nice,  1.7% system,  0.1% interrupt,  0.0% idle
Mem: 1069M Active, 1411M Inact, 269M Laundry, 20G Wired, 1076M Free
ARC: 16G Total, 1234M MFU, 14G MRU, 83M Anon, 201M Header, 786M Other
 14G Compressed, 30G Uncompressed, 2.09:1 Ratio
Swap: 24G Total, 533M Used, 23G Free, 2% Inuse

  PID USERNAME   THR PRI NICE   SIZERES STATE   C   TIMEWCPU COMMAND
24284 root 1  920   228M   199M CPU66   0:11 101.34% c++
24287 root 1  910   269M   241M CPU33   0:10 101.32% c++
24266 root 1  970   303M   276M CPU00   0:17 101.13% c++
24297 root 1  850   213M   184M CPU11   0:06  98.40% c++
24281 root 1  930   245M   217M CPU77   0:12  96.76% c++
24300 root 1  760   114M 89268K RUN 2   0:02  83.22% c++
24303 root 1  750   105M 79908K CPU44   0:01  59.94% c++
24302 root 1  520 74940K 47264K wait4   0:00   0.35% c++
24299 root 1  520 74960K 47268K wait2   0:00   0.33% c++
20954 root 1  200 15528K  4900K zio->i  3   0:02   0.11% cp

ARC is limited to 18 GB to leave 6 GB RAM for use by kernel and user programs.

vfs.zfs.arc_meta_limit: 45
vfs.zfs.arc_free_target: 42339
vfs.zfs.compressed_arc_enabled: 1
vfs.zfs.arc_grow_retry: 60
vfs.zfs.arc_shrink_shift: 7
vfs.zfs.arc_average_blocksize: 8192
vfs.zfs.arc_no_grow_shift: 5
vfs.zfs.arc_min:

"Could not allocate I/O space" and "intsmb0 attach returned 6" in a under-Hyper-V context on Ryzen Threadripper: Is this expected?

2018-04-01 Thread Mark Millard 
For:

# uname -apKU
FreeBSD FBSDHUGE 12.0-CURRENT FreeBSD 12.0-CURRENT  r331831M  amd64 amd64 
1200060 1200060

I get:

. . .
pci0:  at device 7.3 (no driver attached)
. . .
intsmb0:  at device 7.3 on pci0
intsmb0: Could not allocate I/O space
device_attach: intsmb0 attach returned 6

on a Ryzen Threadripper 1950X where FreeBSD is being run under
Hyper-V (on a Windows 10 Pro machine).

Is this expected? Did I misconfigure something in Hyper-V?

This may have been true for a long time and I just
had not noticed until now.

For reference:

# pciconf -l
hostb0@pci0:0:0:0:  class=0x06 card=0x chip=0x71928086 rev=0x03 
hdr=0x00
isab0@pci0:0:7:0:   class=0x060100 card=0x1414 chip=0x71108086 rev=0x01 
hdr=0x00
atapci0@pci0:0:7:1: class=0x010180 card=0x chip=0x71118086 rev=0x01 
hdr=0x00
none0@pci0:0:7:3:   class=0x068000 card=0x chip=0x71138086 rev=0x02 
hdr=0x00
vgapci0@pci0:0:8:0: class=0x03 card=0x chip=0x53531414 rev=0x00 
hdr=0x00

# pciconf -l -v 0:0:7:3
none0@pci0:0:7:3:   class=0x068000 card=0x chip=0x71138086 rev=0x02 
hdr=0x00
vendor = 'Intel Corporation'
device = '82371AB/EB/MB PIIX4 ACPI'
class  = bridge

And . . .

Hyper-V Version: 10.0.16299 [SP0]
  
Features=0x2e7f
  PM Features=0x0 [C2]
  Features3=0xbed7b2
Timecounter "Hyper-V" frequency 1000 Hz quality 2000
CPU: AMD Ryzen Threadripper 1950X 16-Core Processor  (3393.73-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x800f11  Family=0x17  Model=0x1  Stepping=1
  
Features=0x1783fbff
  
Features2=0xfed83203
  AMD Features=0x2e500800
  AMD Features2=0x3f3
  Structured Extended 
Features=0x201c01a9
  XSAVE Features=0xf
  AMD Extended Feature Extensions ID EBX=0x4
Hypervisor: Origin = "Microsoft Hv"
real memory  = 53687091200 (51200 MB)
avail memory = 52206305280 (49787 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 29 CPUs
FreeBSD/SMP: 1 package(s) x 29 core(s)



The local changes to /usr/src/ are mostly tied to
powerpc64 and powerpc experimental activity, but
there is some arm64 and arm material:

# svnlite status /usr/src/ | sort
?   /usr/src/nohup.out
?   /usr/src/sys/amd64/conf/GENERIC-DBG
?   /usr/src/sys/amd64/conf/GENERIC-NODBG
?   /usr/src/sys/arm/conf/GENERIC-DBG
?   /usr/src/sys/arm/conf/GENERIC-NODBG
?   /usr/src/sys/arm64/conf/GENERIC-DBG
?   /usr/src/sys/arm64/conf/GENERIC-NODBG
?   /usr/src/sys/dts/arm/a83t.dtsi
?   /usr/src/sys/dts/arm/sinovoip-bpi-m3.dts
?   /usr/src/sys/dts/arm/sun8i-a83t-sinovoip-bpi-m3.dts
?   /usr/src/sys/dts/arm/sun8i-a83t.dtsi
?   /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG
?   /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG
?   /usr/src/sys/powerpc/conf/GENERICvtsc-DBG
?   /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
M   /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
M   /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
M   /usr/src/crypto/openssl/crypto/armcap.c
M   /usr/src/lib/libkvm/kvm_powerpc.c
M   /usr/src/lib/libkvm/kvm_private.c
M   /usr/src/stand/defs.mk
M   /usr/src/stand/powerpc/boot1.chrp/Makefile
M   /usr/src/stand/powerpc/kboot/Makefile
M   /usr/src/sys/arm64/arm64/identcpu.c
M   /usr/src/sys/conf/kmod.mk
M   /usr/src/sys/conf/ldscript.powerpc
M   /usr/src/sys/kern/subr_pcpu.c
M   /usr/src/sys/modules/dtb/allwinner/Makefile
M   /usr/src/sys/powerpc/aim/mmu_oea64.c
M   /usr/src/sys/powerpc/ofw/ofw_machdep.c
M   /usr/src/sys/powerpc/powerpc/interrupt.c
M   /usr/src/sys/powerpc/powerpc/mp_machdep.c
M   /usr/src/sys/powerpc/powerpc/trap.c
M   /usr/src/usr.bin/top/machine.c

I've modified top to show "MaxObsUsed" (Maximum Observed
used) for Swap when it is positive:

Swap: 194G Total, 4235M Used, 4235M MaxObsUsed, 190G Free, 2% Inuse, 416K In


===
Mark Millard
marklmi26-fbsd at yahoo.com
( dsl-only.net went
away in early 2018-Mar)






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

Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

2018-04-01 Thread Mark Millard 
Andriy Gapon avg at FreeBSD.org wrote on
Tue Mar 27 14:00:20 UTC 2018 :

> First, it looks like maybe several different issues are being discussed and
> possibly conflated in this thread.

It looks like one of the issues that contributes to non-ZFS contexts
seeing process-kills for out-of-swap when there is plenty left has
been identified in the code for head. See:

https://lists.freebsd.org/pipermail/svn-src-head/2018-April/111629.html

It looks like Mark Johnston will be checking something in to help
but there is more to do after that for what was identified.


Overall about the reporting:

Despite lots of hypothesizing beyond the evidence presented, I'm glad for
the reports of issues from multiple types of environments and to known of
types of contexts multiple folks have seen somewhat similar problems with.
Separating issues out can be difficult and time consuming. Knowing what
all needs eventual coverage helps guide things as progress is made. This
is true even for those that are just looking to pick up the eventual
fix(es) for the problem(s) they happen to have run into.

===
Mark Millard
marklmi26-fbsd at yahoo.com
( dsl-only.net went
away in early 2018-Mar)






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

Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

2018-04-01 Thread Don Lewis 
On 27 Mar, Andriy Gapon wrote:
> On 24/03/2018 01:21, Bryan Drewery wrote:
>> On 3/20/2018 12:07 AM, Peter Jeremy wrote:
>>>
>>> On 2018-Mar-11 10:43:58 -1000, Jeff Roberson  
>>> wrote:
 Also, if you could try going back to r328953 or r326346 and let me know if 
 the problem exists in either.  That would be very helpful.  If anyone is 
 willing to debug this with me contact me directly and I will send some 
 test patches or debugging info after you have done the above steps.
>>>
>>> I ran into this on 11-stable and tracked it to r326619 (MFC of r325851).
>>> I initially got around the problem by reverting that commit but either
>>> it or something very similar is still present in 11-stable r331053.
>>>
>>> I've seen it in my main server (32GB RAM) but haven't managed to reproduce
>>> it in smaller VBox guests - one difficulty I faced was artificially filling
>>> ARC.
> 
> First, it looks like maybe several different issues are being discussed and
> possibly conflated in this thread.  I see reports related to ZFS, I see 
> reports
> where ZFS is not used at all.  Some people report problems that appeared very
> recently while others chime in with "yes, yes, I've always had this problem".
> This does not help to differentiate between problems and to analyze them.
> 
>> Looking at the ARC change you referred to from r325851
>> https://reviews.freebsd.org/D12163, I am convinced that ARC backpressure
>> is completely broken.
> 
> Does your being convinced come from the code review or from experiments?
> If the former, could you please share your analysis?
> 
>> On my 78GB RAM system with ARC limited to 40GB and
>> doing a poudriere build of all LLVM and GCC packages at once in tmpfs I
>> can get swap up near 50GB and yet the ARC remains at 40GB through it
>> all.  It's always been slow to give up memory for package builds but it
>> really seems broken right now.
> 
> Well, there are multiple angles.  Maybe it's ARC that does not react properly,
> or maybe it's not being asked properly.
> 
> It would be useful to monitor the system during its transition to the state 
> that
> you reported.  There are some interesting DTrace probes in ARC, specifically
> arc-available_memory and arc-needfree are first that come to mind.  Their
> parameters and how frequently they are called are of interest.  VM parameters
> could be of interest as well.
> 
> A rant.
> 
> Basically, posting some numbers and jumping to conclusions does not help at 
> all.
> Monitoring, graphing, etc does help.
> ARC is a complex dynamic system.
> VM (pagedaemon, UMA caches) is a complex dynamic system.
> They interact in a complex dynamic ways.
> Sometimes a change in ARC is incorrect and requires a fix.
> Sometimes a change in VM is incorrect and requires a fix.
> Sometimes a change in VM requires a change in ARC.
> These three kinds of problems can all appear as a "problem with ARC".
> 
> For instance, when vm.lowmem_period was introduced you wouldn't find any 
> mention
> of ZFS/ARC.  But it does affect period between arc_lowmem() calls.
> 
> Also, pin-pointing a specific commit requires proper bisecting and proper
> testing to correctly attribute systemic behavior changes to code changes.

I just upgraded my main package build box (12.0-CURRENT, 8 cores, 32 GB
RAM) from r327616 to r331716.  I was seeing higher swap usage and larger
ARC sizes before the upgrade than I remember from the distant past, but
ARC was still at least somewhat responsive to memory pressure and I
didn't notice any performance issues.

After the upgrade, ARC size seems to be pretty unresponsive to memory
demand.  Currently the machine is near the end of a poudriere run to
build my usual set of ~1800 ports.  The only currently running build is
chromium and the machine is paging heavily.  Settings of interest are:
  USE_TMPFS="wrkdir data localbase"
  ALLOW_MAKE_JOBS=yes

last pid: 96239;  load averages:  1.86,  1.76,  1.83up 3+14:47:00  12:38:11
108 processes: 3 running, 105 sleeping
CPU: 18.6% user,  0.0% nice,  2.4% system,  0.0% interrupt, 79.0% idle
Mem: 129M Active, 865M Inact, 61M Laundry, 29G Wired, 1553K Buf, 888M Free
ARC: 23G Total, 8466M MFU, 10G MRU, 5728K Anon, 611M Header, 3886M Other
 17G Compressed, 32G Uncompressed, 1.88:1 Ratio
Swap: 40G Total, 17G Used, 23G Free, 42% Inuse, 4756K In

  PID USERNAME   THR PRI NICE   SIZERES STATE   C   TIMEWCPU COMMAN
96239 nobody   1  760   140M 93636K CPU55   0:01  82.90% clang-
96238 nobody   1  750   140M 92608K CPU77   0:01  80.81% clang-
 5148 nobody   1  200   590M   113M swread  0   0:31   0.29% clang-
57290 root 1  200 12128K  2608K zio->i  7   8:11   0.28% find
78958 nobody   1  200   838M   299M swread  0   0:23   0.19% clang-
97840 nobody   1  200   698M   140M swread  4   0:27   0.13% clang-
96066 nobody   1  200   463M   104M swread  1   0:32   0.12%

Re: freebsd-update: to a specific patch level - help please? [PATCH]

2018-04-01 Thread Derek (freebsd lists) 

On 18-03-24 10:26 AM, Derek wrote:

On 18-03-23 06:44 AM, Kurt Jaeger wrote:

To be clear, *I've included a link to a patch to freebsd-update
in my initial post, and the help I'm looking for: is to get this
functionality added as a feature so others can benefit.*  It
works for me already, and I've already benefited.


Please submit this in a PR, and post the PR number here, I'll 
work to

get this in the tree.



PR is 226893



FYI - Just awaiting any kind of feedback on the PC.  Won't be 
starting anything until then.


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

Re: Extremely low disk throughput under high compute load

2018-04-01 Thread Warner Losh 
On Sun, Apr 1, 2018 at 9:18 AM, Stefan Esser  wrote:

> My i7-2600K based system with 24 GB RAM was in the midst of a buildworld
> -j8
> (starting from a clean state) which caused a load average of 12 for more
> than
> 1 hour, when I decided to move a directory structure holding some 10 GB to
> its
> own ZFS file system. File sizes varied, but were mostly in the range 0f
> 500KB.
>
> I had just thrown away /usr/obj, but /usr/src was cached in ARC and thus
> there
> was nearly no disk activity caused by the buildworld.
>
> The copying proceeded at a rate of at most 10 MB/s, but most of the time
> less
> than 100 KB/s were transferred. The "cp" process had a PRIO of 20 and thus
> a
> much better priority than the compute bound compiler processes, but it got
> just 0.2% to 0.5% of 1 CPU core. Apparently, the copy process was scheduled
> at such a low rate, that it only managed to issue a few controller writes
> per
> second.
>
> The system is healthy and does not show any problems or anomalies under
> normal use (e.g., file copies are fast, without the high compute load).
>
> This was with SCHED_ULE on a -CURRENT without WITNESS or malloc debugging.
>
> Is this a regression in -CURRENT?
>

Does 'sync' push a lot of I/O to the disk?

Is the effective throughput of CP tiny or large? It's tiny, if I read
right, and the I/O is slow (as opposed to it all buffering in memory and
being slow to drain own), right?

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

Extremely low disk throughput under high compute load

2018-04-01 Thread Stefan Esser 
My i7-2600K based system with 24 GB RAM was in the midst of a buildworld -j8
(starting from a clean state) which caused a load average of 12 for more than
1 hour, when I decided to move a directory structure holding some 10 GB to its
own ZFS file system. File sizes varied, but were mostly in the range 0f 500KB.

I had just thrown away /usr/obj, but /usr/src was cached in ARC and thus there
was nearly no disk activity caused by the buildworld.

The copying proceeded at a rate of at most 10 MB/s, but most of the time less
than 100 KB/s were transferred. The "cp" process had a PRIO of 20 and thus a
much better priority than the compute bound compiler processes, but it got
just 0.2% to 0.5% of 1 CPU core. Apparently, the copy process was scheduled
at such a low rate, that it only managed to issue a few controller writes per
second.

The system is healthy and does not show any problems or anomalies under
normal use (e.g., file copies are fast, without the high compute load).

This was with SCHED_ULE on a -CURRENT without WITNESS or malloc debugging.

Is this a regression in -CURRENT?

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

Re: Call for Testing: UEFI Changes

2018-04-01 Thread Tomoaki AOKI 
Confirmed both loader (with boot1) part and efirt.ko part.
Working OK on my ThinkPad420 (with nvidia GPU) at r331864.

No benefit (VGA resolution) but no new harm (no panic nor silent
reboot).

 *Maybe gracefully falling back to mode 0.

As I'm on x11/nvidia-driver, completely no test is done with
drm-next.

One more to mention.
I've cherry-picked r330868, r331241 and r331361 on stable/11 after
r331114, amd64 and works OK as on head.
Additional cherry-picking of r331365 is OK, too.

Without r330868, my ThinkPad silently reboots within about 10-60
minutes range, maybe by actual access to UEFI RS.
With r331241 without r331361 causes instant panic on loading efirt.ko.
So all 3 (4) revs should be MFC'ed together.

Sorry for delay.


On Thu, 22 Mar 2018 10:34:33 -0500
Kyle Evans  wrote:

> On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans  wrote:
> > On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei  wrote:
> >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote:
> >>> Hi.
> >>> For problem 2, try reverting r331241 alone.
> >>> This worked for my ThinkPad T420.
> >>
> >>
> >> I also hit this after updating to latest and was about to post when I
> >> saw this thread -
> >>
> >> I build efirt into the kernel and it's now doing a panic on boot. It
> >> appears to be due to this recent addition in dev/efidev/efirt.c by r331241:
> >>
> >>> if (!efi_is_in_map(map, efihdr->memory_size / 
> >>> efihdr->descriptor_size,
> >>> efihdr->descriptor_size, 
> >>> (vm_offset_t)efi_runtime->rt_gettime)) {
> >>
> >> The faulting address is for "efi_runtime->rt_gettime" (and is still a
> >> phys addr here).
> >>
> >
> > The following patch [1] (I can't guarantee how long he'll keep it
> > available there) should fix this class of problems.
> >
> > [1] 
> > https://people.freebsd.org/~andrew/0001-Enter-into-the-EFI-environment-before-check-the-GetT.patch
> 
> Now committed as of r331361.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 


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

Re: i386 4/4 change

2018-04-01 Thread Bruce Evans 


On Sun, 1 Apr 2018, Dimitry Andric wrote:


On 31 Mar 2018, at 17:57, Bruce Evans  wrote:


On Sat, 31 Mar 2018, Konstantin Belousov wrote:


the change to provide full 4G of address space for both kernel and
user on i386 is ready to land.  The motivation for the work was to both
mitigate Meltdown on i386, and to give more breazing space for still
used 32bit architecture.  The patch was tested by Peter Holm, and I am
satisfied with the code.

If you use i386 with HEAD, I recommend you to apply the patch from
https://reviews.freebsd.org/D14633
and report any regressions before the commit, not after.  Unless
a significant issue is reported, I plan to commit the change somewhere
at Wed/Thu next week.

Also I welcome patch comments and reviews.


It crashes at boot time in getmemsize() unless booted with loader which
I don't want to use.



For me, it at least compiles and boots OK, but I'm one of those crazy
people who use the default boot loader. ;)


I found a quick fix and sent it to kib.  (2 crashes in vm86 code for memory
sizing.  This is not called if loader is used && the system has smap.  Old
systems don't have smap, so they crash even if loader is used.)


I haven't yet run any performance tests, I'll try building world and a
few large ports tomorrow.  General operation from the command line does
not feel "sluggish" in any way, however.


Further performance tests:
- reading /dev/zero using tinygrams is 6 times slower
- read/write of a pipe using tinygrams is 25 times slower.  It also gives
  unexpected values in wait statuses on exit, hopefully just because the
  bug is in the test program is exposed by the changed timing (but later
  it also gave SIGBUS errors).  This does a context switch or 2 for every
  read/write.  It now runs 7 times slower using 2 4.GHz CPUs than in
  FreeBSD-5 using 1 2.0 GHz CPU.  The faster CPUs and 2 of them used to
  make it run 4 times faster.  It shows another slowdown since FreeBSD-5,
  and much larger slowdowns since FreeBSD-1:

  1996 FreeBSD on P1  133MHz:   72k/s
  1997 FreeBSD on P1  133MHz:   44k/s (after dyson's opts for large sizes)
  1997 Linux   on P1  133MHz:   93k/s (simpler is faster for small sizes)
  1999 FreeBSD on K6  266MHz:  129k/s
  2018 FBSD-~5 on AthXP 2GHz:  696k/s
  2018 FreeBSD on i7  2x4GHz: 2900k/s
  2018 FBSD4+4 on i7  2x4GHz:  113k/s (faster than Linux on a P1 133MHz!!)

Netblast to localhost has much the same 6 times slowness as reading
/dev/zero using tinygrams.  This is the slowdown for syscalls.
Tinygrams are hard to avoid for UDP.  Even 1500 bytes is a tinygram
for /dev/zero.  Without 4+4, localhost is very slow because it does
a context switch or 2 for every packet (even with 2 CPUs when there is
no need to switch).  Without 4+4 this used to cost much the same as the
context switches for the pipe benchmark.  Now it costs relatively much
less since (for netblast to localhost) all of the context switches are
between kernel threads.

The pipe benchmark uses select() to avoid busy-waiting.  That was good
for UP.  But for SMP with just 2 CPUs, it is better to busy-wait and
poll in the reader and writer.

netblast already uses busy-waiting.  It used to be a bug that select()
doesn't work on sockets, at least for UDP, so blasting using busy-waiting
is the only possible method (timeouts are usually too coarse-grained to
go as fast as blasting, and if they are fine-grained enough to go fast
then they are not much better than busy-waiting with time wasted for
setting up timeouts).  SMP makes this a feature.  It forces use of busy-
waiting, which is best if you have a CPU free to run it and this method
doesn't take to much power.

Context switches to task queues give similar slowness.  This won't be
affected by 4+4 since task queues are in the kernel.  I don't like
networking in userland since it has large syscall and context switch
costs.  Increasing these by factors of 6 and 25 doesn't help.  It
can only be better by combining i/o in a way that the kernel neglects
to do or which is imposed by per-packet APIs.  Slowdown factors of 6
or 25 require the combined i/o to be 6 or 25 larger to amortise the costs.

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